On Tue, May 15, 2007 at 08:43:07AM +0200, felix winkelmann wrote: > On 5/15/07, Peter Keller <[EMAIL PROTECTED]> 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 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
