Thread: [Plib-devel] Creating shared libs or plib under Linux
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Hans de G. <j.w...@hh...> - 2006-06-02 20:48:45
|
Hi, First a short intro (again). I'm a Linux enthousiast / programmer and a packager for Fedora Extras which is an online community that packages software in the native package format for Fedora Core a (well known) Linux distribution. I've recently taken over as the plib Fedora package maintainer and I'm going to create a new plib-1.8 package which will create shared libraries (.so) files instead of the .a files which plib-1.8 currently creates. Note that other distros like Debian and Ubuntu already do this. (there are very good reasons to prefer .so files even for very small pieces of shared code) Now I can quickly hack something together for the .so file creation (as debian has done) or do this properly. Hacking something together is much quicker for me. Thus the question is are you (the plib developers) willing to merge proper written shared lib patches into plib cvs and thus plibs next release? If you are then I'll go and create proper patches if not the hackish way sounds tempting. Thanks & Regards, Hans |
|
From: Bram S. <br...@sa...> - 2006-06-02 20:52:54
|
I believe that it was Steve Baker's intention to do static only, to avoid issues with incompatibilities. Basically, static libs are more foolproof. Then again, is plib LGPL? If so, you cannot create a commercial game with plib and use a static lib. LGPL requires dynamic libs. Bram Hans de Goede wrote: > Hi, > > First a short intro (again). I'm a Linux enthousiast / programmer and a > packager for Fedora Extras which is an online community that packages > software in the native package format for Fedora Core a (well known) > Linux distribution. > > I've recently taken over as the plib Fedora package maintainer and I'm > going to create a new plib-1.8 package which will create shared > libraries (.so) files instead of the .a files which plib-1.8 currently > creates. Note that other distros like Debian and Ubuntu already do this. > (there are very good reasons to prefer .so files even for very small > pieces of shared code) > > Now I can quickly hack something together for the .so file creation (as > debian has done) or do this properly. Hacking something together is much > quicker for me. Thus the question is are you (the plib developers) > willing to merge proper written shared lib patches into plib cvs and > thus plibs next release? If you are then I'll go and create proper > patches if not the hackish way sounds tempting. > > Thanks & Regards, > > Hans > > > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Hans de G. <j.w...@hh...> - 2006-06-02 20:57:00
|
Bram Stolk wrote: > I believe that it was Steve Baker's intention to do static only, > to avoid issues with incompatibilities. > > Basically, static libs are more foolproof. > Actually static libs are a very good ways to keep being bitten by old bugs. What happens when a static lib gets a bugfix? Either all packages build against the previous version must be rebuild, or they keep the bug. > Then again, is plib LGPL? > If so, you cannot create a commercial game with plib and use > a static lib. LGPL requires dynamic libs. > Yes PLIB is LGPL, but that is a rather black and white explanation of the LGPL (I'm not saying its wrong though). But you seem to be the most active plib developer at the moment, are you interested in a patch adding sharedlib support. (Notice this will require that you keep the ABI to plib stable between major releases. Expanidng is ok, changing not. See my fullscreen patch as an example how you can safely expand the ABI (99% == API)). Regards, Hans |
|
From: Bram S. <br...@sa...> - 2006-06-02 21:07:24
|
Hans, There is a whole list of pending bugfixes on the mlist. The development of plib is awaiting a migration. sf cvs service is f****d up. Steve mentioned his intent on moving to SVN, and then plib dev can resume. Steve, do you have a status update to the svn migration? Bram Hans de Goede wrote: > > Bram Stolk wrote: > >>I believe that it was Steve Baker's intention to do static only, >>to avoid issues with incompatibilities. >> >>Basically, static libs are more foolproof. >> > > > Actually static libs are a very good ways to keep being bitten by old > bugs. What happens when a static lib gets a bugfix? Either all packages > build against the previous version must be rebuild, or they keep the bug. > > >>Then again, is plib LGPL? >>If so, you cannot create a commercial game with plib and use >>a static lib. LGPL requires dynamic libs. >> > > > Yes PLIB is LGPL, but that is a rather black and white explanation of > the LGPL (I'm not saying its wrong though). > > But you seem to be the most active plib developer at the moment, are you > interested in a patch adding sharedlib support. (Notice this will > require that you keep the ABI to plib stable between major releases. > Expanidng is ok, changing not. See my fullscreen patch as an example how > you can safely expand the ABI (99% == API)). > > Regards, > > Hans > > > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Hans de G. <j.w...@hh...> - 2006-06-03 08:35:56
|
Bram Stolk wrote: > Hans, > > There is a whole list of pending bugfixes on the mlist. Is there a single place where one can easily see an overview of these fixes? That would be of great help to people building plib packages for Linux distros like me. Do these patches apply against 1.8.4 or against CVS? Talking about CVs is the current CVS significantly different from 1.8.4, any API changes? > The development of plib is awaiting a migration. > sf cvs service is f****d up. > I'm a contributer to other sf hosted projects and sf CVS is working fine for them. I would like to suggest to not freeze development and instead keep using CVS for now. Once a SVN move is iactually going to be happen, then its time to freeze. I don't see how freezing now, while the SVN migration has no clear timeline, is going to help plib development. > Steve mentioned his intent on moving to SVN, and then > plib dev can resume. > > Steve, do you have a status update to the svn migration? > It seems to me that plib development is a bit stuck at everyone waiting one Steve and Steve not having time todo any work on plib, why don't you (the community) take over / why doesn't Steve hand over leadership to someone else? Regards, Hans p.s. You still didn't answer my question, does a proper written shared lib support patch have a chance of getting merged? I know ask Steve, well since he is not answering I'm asking you (the community) so what do you think? |
|
From: Bram S. <br...@sa...> - 2006-06-03 09:03:45
|
Hans de Goede wrote: > > Bram Stolk wrote: > >>Hans, >> >>There is a whole list of pending bugfixes on the mlist. > > > Is there a single place where one can easily see an overview of these > fixes? That would be of great help to people building plib packages for > Linux distros like me. Well... the submissions come in from the mailing list, so you can check the mailing list archive, or else check cvs logs. > > Do these patches apply against 1.8.4 or against CVS? Depends on what the submitter used. > Talking about CVs is the current CVS significantly different from 1.8.4, > any API changes? I know of at least some api changes: classes were moved (and renamed) from pu to puAux. > > >>The development of plib is awaiting a migration. >>sf cvs service is f****d up. >> > > I'm a contributer to other sf hosted projects and sf CVS is working fine > for them. I would like to suggest to not freeze development and instead > keep using CVS for now. Once a SVN move is iactually going to be happen, > then its time to freeze. I don't see how freezing now, while the SVN > migration has no clear timeline, is going to help plib development. Well... it may not be the fastest way for plib devel, but at least it avoids double work where patches may have to be applied twice. And yes... I just checked the SF status page, and CVS seems to be back up. > > >>Steve mentioned his intent on moving to SVN, and then >>plib dev can resume. >> >>Steve, do you have a status update to the svn migration? >> > > > It seems to me that plib development is a bit stuck at everyone waiting > one Steve and Steve not having time todo any work on plib, why don't you > (the community) take over / why doesn't Steve hand over leadership to > someone else? I don't have time to maintain plib. I have some spare time to assist with some work on it, but not to be the main maintainer. I just want plib to be in a stage as fit as possible, when I release my own plib based game. For this I'm helping out both plib and opende to get a solid release. > > Regards, > > Hans > > > p.s. > > You still didn't answer my question, does a proper written shared lib > support patch have a chance of getting merged? I know ask Steve, well > since he is not answering I'm asking you (the community) so what do you > think? Well, I've come to know Steve as a very knowledgable engineer. Often, what seemed to be reasonable suggestions, were quite professionaly analyzed by him, and afterwards you had to agree that his insights were pretty spot on. Let me see if I can dig up the original reasoning for not doing shared libs, and see if they hold up today. (I'm affraid they do, though :-) But first: what is the exact reason for you wanting to have shared libs? Do you want to package multiple plib games for a distro and need to spare the redudancy? Bram > > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Bram S. <br...@sa...> - 2006-06-03 09:22:32
|
Bram Stolk wrote: > Let me see if I can dig up the original reasoning for not doing shared > libs, and see if they hold up today. (I'm affraid they do, though :-) These arguments from 1999 still seem quite compelling :-) http://lists.debian.org/debian-mentors/1999/11/msg00038.html bram |
|
From: Hans de G. <j.w...@hh...> - 2006-06-03 15:31:08
|
Bram Stolk wrote: > Bram Stolk wrote: > >> Let me see if I can dig up the original reasoning for not doing shared >> libs, and see if they hold up today. (I'm affraid they do, though :-) > > These arguments from 1999 still seem quite compelling :-) > > http://lists.debian.org/debian-mentors/1999/11/msg00038.html > > bram > Yes, proper library versioning is always important when creating shared libs and often is used as an argument against shared libs, but one would expect a library to have a stable API/ABI only changing it on a major new release. If you need to change your API/ABI often you didn't do a good job with your API design in the first place. Regards, Hans |
|
From: Hans de G. <j.w...@hh...> - 2006-06-03 09:49:32
|
Bram Stolk wrote: <snip> > But first: what is the exact reason for you wanting to have shared libs? > Do you want to package multiple plib games for a distro and need to spare > the redudancy? > We already ship multiple plib games and plan to package more in the future. It isn't about sparing the redundancy in terms of diskspace, let alone the very theoretically lower memory usage when running multiple plib using games at once (who would want to run multiple games at once). There is only one reason for wanting shared libs and thats a very good reason: with shared libs if a bug is found in plib (and no piece of code is bugfree) we only need to release an updated plib package which the fixed shared libs and all plib using programs / games will magicly pick up the bugfix. The other scenario requires me (the plib maintainer) to poke everyone who maintains a plib based package todo a rebuild and requires end users to download many updated games instead of a single update. This is only one reason but a _very_ important reason. Actually one of the things I as a packager (and others) spend quite a bit of time on is to remove copies of library-sources from sources as distributed by upstream. You have no idea how many times upstream developers think lets make it easier for end users to compile this and drop copies of libraries they need into the source tarbal. I think before we started cleaning things like this up an average linux distro had atleast 30 copies of zlib in its source archives, until the zlib security bugs started hitting us, scrambling out 30 security fixes which should have been just 1 is no fun (at all). Now the zlib scenario was even worse, because the packages did not only need a rebuild but all those separate copies needed separate patching first! So now most distros (atleast Debian and Fedora) try to avoid this as much as possible. Debian has been shipping a plib patched to build .so files for ages, Fedora hasn't been shipping plib for long and fixing this has been on our todo from day one. Just to make things clear the question isn't if Fedora is going to be shipping shared libs for plib, the question is if this is going to be a patch on top of plib which we will have to maintain for as long as we ship plib or if this can be integrated upstream. Where I ofcourse prefer getting things integrated upstream. Regards, Hans |
|
From: steve <sjb...@ai...> - 2006-06-04 19:43:06
|
Hans de Goede wrote:
>
> Bram Stolk wrote:
> <snip>
>
>>But first: what is the exact reason for you wanting to have shared libs?
>>Do you want to package multiple plib games for a distro and need to spare
>>the redudancy?
>>
>
>
> We already ship multiple plib games and plan to package more in the
> future. It isn't about sparing the redundancy in terms of diskspace, let
> alone the very theoretically lower memory usage when running multiple
> plib using games at once (who would want to run multiple games at once).
>
> There is only one reason for wanting shared libs and thats a very good
> reason: with shared libs if a bug is found in plib (and no piece of code
> is bugfree) we only need to release an updated plib package which the
> fixed shared libs and all plib using programs / games will magicly pick
> up the bugfix.
That's another urban legend.
I've been supporting these kinds of applications since before Tux the
Penguin - A Quest for Herring was released in 1998. Here is the
truth:
All it takes is something like:
class ssgThing
{
char *second ;
int first ;
public:
void setFirst ( int x ) { first = x ; }
void setSecond ( char *y ) ;
}
...then in the '.cxx' file:
void ssgThing::setSecond { char *y ) { second = y ; }
...then, a year later, some enthusiastic contributer looks at
'class ssgThing' and thinks it would look nicer if the
fields 'first' and 'second' were in the right order...
class ssgThing
{
int first ;
char *second ;
public:
void setFirst ( int x ) { first = x ; }
void setSecond ( char *y ) ;
}
(or he adds a variable - or changes it's type or adds a virtual
function or changes a defaulting parameter or...almost anything
acutally)
...now we recompile the library and rerelease it - and KABLOOIE - every
single dynamically linked binary crashes because 'setFirst' in the
application scribbles over 'second' in the library and you get the
weirdest crashes in formerly working applications.
To be clear here - there was no bug in the older PLIB, no bug in the
newer PLIB and no bug in the application...yet still it crashes.
Dunno about you - but I don't fancy trying to debug a fatal crash
in a working program running on a working library - when the only
feedback we get from end users is "It crashed".
Since the poor end user has NO IDEA that some application happens to
use PLIB, he'll have no idea why installing some library that some
new game needs causes his favorite old game to crash when it worked
perfectly before.
So whilst there are times when upgrading PLIB might fix bugs in older
applications - there are just as many times when it CAUSES bugs in
perfectly working programs.
If those old applications had actually been TESTED, released and
were working when whatever version of PLIB they compiled against
couldn't possibly have had any really serious bugs that those
applications cared about.
So - no - this doesn't help the stability of PLIB applications - it
makes them MUCH less stable.
|
|
From: Hans de G. <j.w...@hh...> - 2006-06-05 07:34:38
|
steve wrote:
> Hans de Goede wrote:
>> Bram Stolk wrote:
>> <snip>
>>
>>> But first: what is the exact reason for you wanting to have shared libs?
>>> Do you want to package multiple plib games for a distro and need to spare
>>> the redudancy?
>>>
>>
>> We already ship multiple plib games and plan to package more in the
>> future. It isn't about sparing the redundancy in terms of diskspace, let
>> alone the very theoretically lower memory usage when running multiple
>> plib using games at once (who would want to run multiple games at once).
>>
>> There is only one reason for wanting shared libs and thats a very good
>> reason: with shared libs if a bug is found in plib (and no piece of code
>> is bugfree) we only need to release an updated plib package which the
>> fixed shared libs and all plib using programs / games will magicly pick
>> up the bugfix.
>
> That's another urban legend.
>
> I've been supporting these kinds of applications since before Tux the
> Penguin - A Quest for Herring was released in 1998. Here is the
> truth:
>
> All it takes is something like:
>
> class ssgThing
> {
> char *second ;
> int first ;
> public:
>
> void setFirst ( int x ) { first = x ; }
> void setSecond ( char *y ) ;
> }
>
>
> ...then in the '.cxx' file:
>
> void ssgThing::setSecond { char *y ) { second = y ; }
>
> ...then, a year later, some enthusiastic contributer looks at
> 'class ssgThing' and thinks it would look nicer if the
> fields 'first' and 'second' were in the right order...
>
> class ssgThing
> {
> int first ;
> char *second ;
> public:
>
> void setFirst ( int x ) { first = x ; }
> void setSecond ( char *y ) ;
> }
>
> (or he adds a variable - or changes it's type or adds a virtual
> function or changes a defaulting parameter or...almost anything
> acutally)
>
> ...now we recompile the library and rerelease it - and KABLOOIE - every
> single dynamically linked binary crashes because 'setFirst' in the
> application scribbles over 'second' in the library and you get the
> weirdest crashes in formerly working applications.
>
> To be clear here - there was no bug in the older PLIB, no bug in the
> newer PLIB and no bug in the application...yet still it crashes.
>
Definitely a bug in the newer plib if you ask me, the answer to the
whole above scenario is simple: don't exchange the 2 variables. The
exact same breakage will happen with plain C when you exchange the
position of 2 variables in a structure. So the whole this is C++ shared
libs can't be done with C++ scenario doesn't fly here. Actually it
doesn't fly at all. Because in essence the problem is the same in both
worlds though shall not change the layout of in memory structures. The
only thing making c++ slightly harder is the fact that the virtual
function table is an in memory structure too.
There are even tricks in the book to allow you to extend in memory
layouts as long as you don't change them. This has been done for ages,
when you program native Xlib for example you must always ask the library
to alloc the WMHints struct for you because the _real_ size is unknown
to applications the struct may contain additional members after those
declared in the header file.
>
> So whilst there are times when upgrading PLIB might fix bugs in older
> applications - there are just as many times when it CAUSES bugs in
> perfectly working programs.
>
Only if you break the ABI and a _bugfix_ release to a library should
never break the ABI.
This is where the way plib is maintained apparently differs hugely from
other libraries (again this is language independent).
Other libraries have a scheme where 1.8.x would all be ABI compatible,
maybe a .x release could introduce new functionality, but done in such a
way that it doesn't break the ABI. Then when you _really_ need to change
the ABI you release 2.0.x (or 1.9.x) and then you're free to exchange
the position of the variables as described above and todo whatever you
want, and you change the soname so that the linker _will_ complain when
an older apps is ran and only this version is installed (with a
different soname both versions can be installed besides eachother).
Now plib doesn't give this ABI stability guarantee and I understand that
you aren't willing to give this guarantee in the future either. (From
what I've heard plib doesn't even offer API stability guarantees).
So lets end this with agreeing on the fact that we disagree. Fedora is
shipping plib .so files as of yesterday with the full release (1.8.4)
as soname, when a bug comes by that needs fixing I'll be sure not to
break the ABI when a new plib is released (say 1.8.5) I'll change the
soname (to 1.8.5) and provide a compatibility package (for 1.8.4 linked
apps) untill all apps are succesfully rebuild and linked against 1.8.5 .
Regards,
Hans
|
|
From: steve <sjb...@ai...> - 2006-06-05 12:36:21
|
Hans de Goede wrote:
> Definitely a bug in the newer plib if you ask me, the answer to the
> whole above scenario is simple: don't exchange the 2 variables.
...or add a virtual function - or change the type of an internal
class member - or almost anything actually.
I sense you havn't tried to maintain a large C++ class library
with dozens of contributors. You can't stop this kind of change -
you just can't be that alert.
> The
> exact same breakage will happen with plain C when you exchange the
> position of 2 variables in a structure.
Yes - but very, very few C API's use structures. In the whole of
the C standard library there are maybe two. Things like the
internals of a FILE are typically hidden.
You just can't do that in C++ and yet still get the benefits of
a class interface.
> So the whole this is C++ shared
> libs can't be done with C++ scenario doesn't fly here.
I'm sorry - but you are wrong. I've been writing C++ libraries
since the very first C++ translator came out from AT&T - and I'm
quite certain of that.
> Actually it
> doesn't fly at all. Because in essence the problem is the same in both
> worlds though shall not change the layout of in memory structures.
Yes - but in C, you design your API without exposed data because C
is a PROCEDURAL language. C++ is HEAVILY data-driven with the
inner workings of your classes necessarily exposed in the '.h' files.
It's the style of programming - not the precise details of the language.
> There are even tricks in the book to allow you to extend in memory
> layouts as long as you don't change them.
Not in a portable and efficient manner.
> This has been done for ages,
> when you program native Xlib for example you must always ask the library
> to alloc the WMHints struct for you because the _real_ size is unknown
> to applications the struct may contain additional members after those
> declared in the header file.
Now mentally extend that to the SSG scene graph structure and see what
an unholy mess you'd end up with.
> This is where the way plib is maintained apparently differs hugely from
> other libraries (again this is language independent).
No - this is how a C++ library has to be maintained.
There aren't a whole lot of heavily C++ libraries out there with the
class objects exposed. Those that do suffer this problem.
> Now plib doesn't give this ABI stability guarantee and I understand that
> you aren't willing to give this guarantee in the future either. (From
> what I've heard plib doesn't even offer API stability guarantees).
We are actually REMARKABLY stable over the years for programs that are
recompiled when they want a new version of PLIB.
> So lets end this with agreeing on the fact that we disagree. Fedora is
> shipping plib .so files as of yesterday with the full release (1.8.4)
> as soname, when a bug comes by that needs fixing I'll be sure not to
> break the ABI when a new plib is released (say 1.8.5) I'll change the
> soname (to 1.8.5) and provide a compatibility package (for 1.8.4 linked
> apps) untill all apps are succesfully rebuild and linked against 1.8.5 .
I have no control over what the distro guys do with this package -
that's what OpenSource is all about - however, they should not expect
binary compatibility between releases because we can't assure that.
Please don't expect us to field queries from users of these distro's
because we simply can't do that if the package was installed incorrectly
by the distro vendors.
If someone comes to us with mysterious errors our reaction will be:
"Oh dear - your copy of PLIB has been installed incorrectly
by Fedora (or whoever) - I suggest you uninstall it and put
it back correctly. If you still have a problem - come back
to us."
...we've seen these kinds of fiasco's many times before from the
RedHat guys - both C++ and Mesa have been grabbed from CVS repositories
in an unfinished or unreleased state and stuffed into their distro.
I'd hoped that PLIB wouldn't suffer the same fate...but there isn't
a good defense of that for an OpenSource library team.
|
|
From: Hans de G. <j.w...@hh...> - 2006-06-05 18:03:12
|
steve wrote: > Hans de Goede wrote: > >> The >> exact same breakage will happen with plain C when you exchange the >> position of 2 variables in a structure. > > Yes - but very, very few C API's use structures. In the whole of > the C standard library there are maybe two. Things like the > internals of a FILE are typically hidden. > There are many C API's which use structures I'll gladly admit I know little about C++ but I can dream in C-code and this simply is not true. > You just can't do that in C++ and yet still get the benefits of > a class interface. > <snip> > No - this is how a C++ library has to be maintained. > > There aren't a whole lot of heavily C++ libraries out there with the > class objects exposed. Those that do suffer this problem. > Thats untrue, see QT/KDE for example or the STL or many others which all work fine with shared-objects and C++. But as I already said: >> lets end this with agreeing on the fact that we disagree. I think thats all there is to it. You are not willing to guarantee a stable ABI, then downstream (Fedora or whatever) should not depend on a stable ABI and thus I won't. As said before I've used the full plib version/release as soname, so if a newer plib gets build it will have a different soname, guaranteeing proper working (or a linker error giving a clear message about the problem). All I'm asking now (and all thats keeping this discussion going) is that you do not defend your stance with clearly false statements like the ones above. <snip> > If someone comes to us with mysterious errors our reaction will be: > > "Oh dear - your copy of PLIB has been installed incorrectly > by Fedora (or whoever) - I suggest you uninstall it and put > it back correctly. If you still have a problem - come back > to us." > > ...we've seen these kinds of fiasco's many times before from the > RedHat guys - both C++ and Mesa have been grabbed from CVS repositories > in an unfinished or unreleased state and stuffed into their distro. > I'd hoped that PLIB wouldn't suffer the same fate...but there isn't > a good defense of that for an OpenSource library team. 1) I'm not RedHat but a volunteer contributer 2) The C++ compiler and Mesa things are off topic 3) Debian (which is known for its stability) has been doing this for ages so solely targeting Fedora for this isn't helping this discussion, instead you should be glad that I'm trying to work this out with you instead of shipping modified packages without ever letting you know which Debian appearantly is doing. Regards, Hans |
|
From: steve <sjb...@ai...> - 2006-06-04 20:34:14
|
Hans de Goede wrote: > It seems to me that plib development is a bit stuck at everyone waiting > one Steve and Steve not having time todo any work on plib, why don't you > (the community) take over / why doesn't Steve hand over leadership to > someone else? I've certainly been too busy with paying work to give PLIB the time it deserves. However: * I don't run this like Linus runs the kernel - I'm not the sole 'gatekeeper' of the golden sources. * There are 24 registered developers - any of whom can incorporate patches into CVS, update documents, maintain the website, etc You don't need me to do this. Here are the 24 developers: Alex Perry alexperry Bram Stolk bram Curtis Olson curt Gerard Decatrel deca Bert Driehuis driehuis John F. Fay fayjf Gil Carter gilcarter J�rgen Marquardt j_marquardt Giancarlo Niccolai jonnymind Will Lachance lachancew Per Liedman liedman Mark K Vallevand markus5 Dave McClurg mcdave Norman Vine nhv Nick McEvoy nmcevoy James Jones puggles J. Nathan Matias rubberpaw Steve Baker sjbaker Eric Lavigne smokydiamond Sam Stickland sps196 M�rten Str�mberg stromberg Sebastian Ude ude Wolfram Kuss wolfram_kuss Ben Woodhead zander76 * I don't believe I've ever turned down anyone who requested developer status. If you plan to regularly commit patches and you aren't a developer - let me know and I'll give you CVS access. * The only tasks you really need me to help out with are those that require admin privilage: + Mailing list settings. + Making releases. + Creating new developers. + Doing stuff like transitioning CVS to SVN. Sooner or later my workload will reduce and I'll get active again - it's just not practical right now - sorry. |
|
From: Norman V. <nh...@ca...> - 2006-06-05 01:45:25
|
steve writes: > > Sooner or later my workload will reduce and I'll get active again - = it'sjust not practical right now - sorry. Cool, bunch of us are waiting for that after all PrettyPoly should be using shaders :-) Ciao nhv =20 |
|
From: Hans de G. <j.w...@hh...> - 2006-06-05 07:44:00
|
steve wrote: > Hans de Goede wrote: > >> It seems to me that plib development is a bit stuck at everyone waiting >> one Steve and Steve not having time todo any work on plib, why don't you >> (the community) take over / why doesn't Steve hand over leadership to >> someone else? > > I've certainly been too busy with paying work to give PLIB the time it > deserves. > > However: > > * I don't run this like Linus runs the kernel - I'm not the sole > 'gatekeeper' of the golden sources. > Good, but the others still seem to want you to act as Linus when a decision has to be taken they all seem to say I have no opinion lets ask Steve. (Which is actually a bit different from how Linus does it, there the others first voice there opinion loudly and then Linus makes the decision if a consensus can't be reached :). Now with the shared lib story I can understand that people want to hear your opinion (besides their own) But why noone sofar has reacted to my pw fullscreen patch is a mistery. Yes I know its Xlib only, I would hope a windows developer to step up and implement the windows version that shouldn't be to hard I think. > * I don't believe I've ever turned down anyone who requested developer > status. If you plan to regularly commit patches and you aren't a > developer - let me know and I'll give you CVS access. > Erm, I'll just lurk around on the list for now to get a hang of things are done in plib and I'll wait and see how many patches for plib I produce. If I get and hit no plib related bugs in my Fedora work I probably won't be doing much plib work and then CVS access won't be necessary. But if I ever feel the need for it I'll ask, thanks! > * The only tasks you really need me to help out with are those that > require admin privilage: > > + Mailing list settings. > + Making releases. > + Creating new developers. > + Doing stuff like transitioning CVS to SVN. > I assume with "you" you mean the plib developer community, not me :) Yes it would be great if someone could step up and to those things. Come one everyone any takers? Regards, Hans |
|
From: steve <sjb...@ai...> - 2006-06-05 12:39:55
|
Hans de Goede wrote: >>* I don't run this like Linus runs the kernel - I'm not the sole >> 'gatekeeper' of the golden sources. > > Good, but the others still seem to want you to act as Linus when a > decision has to be taken they all seem to say I have no opinion lets ask > Steve. (Which is actually a bit different from how Linus does it, there > the others first voice there opinion loudly and then Linus makes the > decision if a consensus can't be reached :). Well, 'life or death' decisions (such as going '.so' or staying '.a') are things I'd like to have a say in - but I'd hope that one or more of those 23 other registered developers would be able to help commit a simple patch. If you'd like to become a registered developer yourself, please send me a request with your sourceforge username and I'll be happy to add you to the list. >>* The only tasks you really need me to help out with are those that >> require admin privilage: >> >> + Mailing list settings. >> + Making releases. >> + Creating new developers. >> + Doing stuff like transitioning CVS to SVN. > > I assume with "you" you mean the plib developer community, not me :) Yes. |
|
From: Martin S. <Mar...@mg...> - 2006-06-03 13:14:40
|
Hans de Goede wrote: > Bram Stolk wrote: >> I believe that it was Steve Baker's intention to do static only, >> to avoid issues with incompatibilities. >> >> Basically, static libs are more foolproof. > > Actually static libs are a very good ways to keep being bitten by old > bugs. I agree that in most situations this is actually the case. PLIB is a bit different here .... When you look at the facts, PLIB, still having active contributors, is actually without maintainer. The former maintainer, as Bram already noted, intended to have static PLIB only. Previously, backwards- compatibility was intentionally and explicitely not cared about - and I myself have been bitten by this several times when I was maintaining my own PLIB-shared-library patch for a while. Currently PLIB is a moving target, the most actual 'release' is what you get out of CVS today; sometimes people add patches that break building PLIB on other people's platform and nobody cares .... (I've been bitten by this as well). I suggest to put this idea of adding such a 'shared-library-mode' to the 'official' PLIB source tree on hold as long as there's no maintainer who'll try to take care of backwards compatilbility with previously issued binaries. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Hans de G. <j.w...@hh...> - 2006-06-03 20:57:08
|
Martin Spott wrote: > > I suggest to put this idea of adding such a 'shared-library-mode' to > the 'official' PLIB source tree on hold as long as there's no > maintainer who'll try to take care of backwards compatilbility with > previously issued binaries. > I agree indeed the most important thing for plib now is to someone actually stand up and say this looks like a cool project for me and then starts pulling the kart, he doesn't need to be alone, but someone has to take the lead. Preferably this someone would be approved by Steve. Notice that I'm not that someone, I'm interested in plib, willing to create patches etc, but I'm not going to pull the kart. Regards, Hans |
|
From: steve <sjb...@ai...> - 2006-06-04 19:28:57
|
Hans de Goede wrote:
>
> Martin Spott wrote:
>
>>I suggest to put this idea of adding such a 'shared-library-mode' to
>>the 'official' PLIB source tree on hold as long as there's no
>>maintainer who'll try to take care of backwards compatilbility with
>>previously issued binaries.
>>
>
>
> I agree indeed the most important thing for plib now is to someone
> actually stand up and say this looks like a cool project for me and then
> starts pulling the kart, he doesn't need to be alone, but someone has to
> take the lead. Preferably this someone would be approved by Steve.
My reluctance to go with shared libraries relates to the nature of
a C++ package.
With a C library, the interface to the package is essentially defined
by the library. So long as you don't add or subtract parameters from
functions, you can pretty much compile against any header and link to
a dynamic library and either it'll work - or you'll get linker errors.
You can use (for example) the OpenGL header from OpenGL 1.0 and if your
program compiles OK, it'll link just fine against any version of OpenGL
after 1.0. If you link against the OpenGL 2.0 header then if you only
use functions from the 1.0 subset, your code will STILL link and run
against OpenGL 1.0 libraries - and even if you use one of the more
modern features, you'll get a runtime linker error and you'll know
you have a problem - cleanly and clearly.
With a C++ library - a substantial fraction of the code is defined by
the classes in the '.h' files - and there are frequently a bunch of
things like inline functions and such.
Someone can do something a simple as changing the order of function
definitions within a class - and if they are virtual functions, the
application will compile and link - and yet fail totally mysteriously
at runtime if it's not linked against precisely the right version
of PLIB. The failure will be some very strange core dump that will
not immediately scream "WRONG VERSION!"...this is a pain to diagnose.
We know this is a problem even for OS'es where code is predominantly
distributed as binaries - but when you have source distro's for so
many games and such you end up depending on header files being
up do date with whatever '.so' is going to be picked up at runtime.
This is bad enough - but if there are multiple '.so' files on the
hard drive - some installed by the distro and others by the end user -
the result is frequently a horrible mess. Yes, if it's "done right",
it all works OK - but look back through the archives and you'll see
that the number of users who screw up their setups is horrifyingly
large. If you have one set of PLIB headers in /usr/include
and another installed (perhaps by the distro) in /usr/X11/include
and yet a third set in /usr/local/include ...then you don't know
for sure whether the application linked against /usr/lib or
/usr/X11/lib or /usr/local/lib....you truly have no idea what's
going on.
This causes a LOT of complaints about non-working code that crashes
in totally strange ways that are virtually impossible for us to
diagnose via email...especially with just a handful of people who
are prepared to help out.
So these are all the reasons why '.so' files are a pain.
The positive benefits of '.so' files IN THIS CONTEXT are less:
1) By sharing libraries, application binaries consume less space
both on disk and in RAM. This is great for libc libm and so
forth - but how many PLIB applications do we have on disk and
in RAM? It's negligable.
2) There are horrible problems with commercial apps linking against
GPL'ed libraries unless they are '.so'. This is urban legend.
A "GPL" library would indeed be a problem for commercial code
that had to link as a '.a' - but go read the PLIB license. We
use 'LGPL' - it specifically allows commercial apps to link to
the '.a' without nasty encumberances. This is a total red
herring. Forget about it.
So - I'm very reluctant to have PLIB build as a '.so' - it'll cause
no end of maintenance problems with essentially zero benefits.
With '.a' files, at least you can distribute binaries that are
pretty much guaranteed to work - and so long as we stick with the
rule that PLIB is *ONLY* installed in /usr/include/plib and /usr/lib,
we'll have sources that always compile against matching headers and
libraries - so we won't have problems with source builds.
This approach hasn't been arrived at lightly - we thought A LOT
about this in the very early days of PLIB and I don't think much
has changed since.
|
|
From: Martin S. <Mar...@mg...> - 2006-06-03 17:13:55
|
Hans de Goede wrote: > Yes, proper library versioning is always important when creating shared > libs and often is used as an argument against shared libs, but one would > expect a library to have a stable API/ABI only changing it on a major > new release. > > If you need to change your API/ABI often you didn't do a good job with > your API design in the first place. As Bram already wrote there was no focus on creating shared libraries from PLIB at all - your criticism is waste. You'd probably better discuss such issues with Steve, not with the poeple who spend their time for keeping PLIB alive, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X