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

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

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.