Re: [Chicken-users] Mac OS X static library names

[Peter Keller]

On Tue, May 15, 2007 at 08:43:07AM +0200, felix winkelmann wrote:
> On 5/15/07, Peter Keller <address@hidden> wrote:
> >Doesn't chicken already have a tool someon can run when linking with
> >chicken applications? Like csc -libs? Why can't you just add -lpcre there
> >if applicable? Then it'll just grab whatever the user wanted.
> 
> Wouldn't that cause versioning problems?

I see you pulling a thread on the tapestry of dynamic linking.... :)

That question goes right to the heart of the fundamental reason of dynamic
linking. The fact that it was partially created to perform easy upgrades
for all programs on a machine.  However, the upgrade needs one thing
to function, and that is a perfect API compatibility with the previous
version of the library. If that constraint is maintained then versioning
problems _nearly_ vanish.

Unfortunately, the real world for UNIX basically works on linux and
solaris. Solaris gets this right far more than you could imagine, linux
couldn't care less if they got it right. These days library authors
don't seem to care that they change the API to a library which is often
shared and that causes a lot of versioning problems with pre-existing
programs--forcing recompiles. It is in fact the reason for the warning
call gcc -static exhibits on modern linux machines--the nss libraries
APIs change so much, they are completely unreliable between even
minor revisions. More than once have I gotten into arguments with
library maintainers where they simply say "Your crap is open source,
just recompile it and it'll be fine." While that might be true, it is
almost like they willfully ignore the issue of binary compatibility.

But yeah, it probably would cause versioning problems over the lifetime
of an executable. Upgrade the host OS a few times, and the dynamic linker
will probably puke (for linux) on the library due to API shift over time.
For solaris, it would probably work for a long time.

It is very tempting to embed these dynamic libraries into your codebase,
but if data movement is allowed between the copies of it in the
executable, only tears and madness will arise.

If you drink a long pull of tequila and look deeply into glibc's symboling
system, you'll notice that functions can have revision numbers attached
to them. This means that a program compiled against glibc 2.3, but
running on a glibc 2.4 machine, will pick a copy of the functions in
the 2.4 glibc which are versions for 2.3 and do different things than
the 2.4 versions.  This stuff is all hacked together specifically to
combat version problems for a "few revisions" of glibc, and the dynamic
linker tries to fix it all up at load time. For the most part this works,
but it is frightenigly difficult to fix when it breaks, such as when you
run a gibc 2.3.4 program against a glibc 2.3.3, and ONE function called
three hours into the execution needs a version of a function from 2.3.4
which the dynamic linker is unable to resolve and it segfaults.

This problem is an elephant in the room in modern linux distributions today.

-pete