Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

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