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

[steve <sjb...@ai...>]

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.