Date: Sun, 20 Sep 1998 09:48:38 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter@netplex.com.au (Peter Wemm) Cc: jabley@clear.co.nz, dholland@cs.toronto.edu, freebsd@xaa.iae.nl, freebsd-current@FreeBSD.ORG Subject: Re: ELF ldconfig Message-ID: <199809200948.CAA14405@usr06.primenet.com> In-Reply-To: <199809200750.PAA17687@spinner.netplex.com.au> from "Peter Wemm" at Sep 20, 98 03:50:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> What this caused, was that all libraries linked against the new library > would cause an annoying warning when run against an older library on a > different system - even though it still ran fine. *if* the new program > used the new symbol, you got the version warning and then an undefined > symbol error. Right; but at least you were warned it was coming. 8-). The main problem is that the ld code needs to enforce the existance of all symbols at link time, and then you are left to your own devices at load time. Right now, it's possbile to link against a shared library that requires a symbol from anothe shared library, and not get any missing symbol warnings during link phase. This has bit me on the butt more than once, especially with libraries with promiscuous symbol reference in other libraries (ie: libraries that know too much about each other). > With our elf implementation as it stands at present, there is no minor > version checking. It either links or it doesn't. As far as I'm > concerned, that's no great loss, and depending on how you think about it, > it could be considered an improvement. Right. The only issue is that you don't get a warning on a down-rev library usage on a system that wasn't the compilation system, like you did with a.out, so an undefined symbol error is bad. One way to resolve this is to force RTLD_NOW in ld.so. Unfortunately, ld.so in both a.out and ELF is a bit too stupid to be able to do this without counding some symbols that it used to count zero times twice instead of once (I tried to make this change for the support of weak symbols in ld.so during the "undefine __error" fiasco, and gave up after 4 hours when I realized it would take fully 40 hours to do the code correctly). > Linux is getting into this in a big way within glibc it seems. Not that > that itself means that we should, but it (in the right situation) can pay > off. I think I saw that they (so far) have used it to emulate an old > stdio (incompatable) implementation without a major version bump. Hum. I am about as unconvinced of this as I am of the versioning of CTL3D32.DLL in Windows 95 and NT. The only way to externally determine if you have the right one is if your application works or fails when you try and run in a non-US ASCII locale. This is bad ju-ju. > > So remind me why ELF is a good idea? :) > > a.out can't do this either. We would have to bump all major library > numbers in a.out because things like the errno -> __error() change in libc > and libtermcap calling issetugid() etc. > > Don't forget, at the moment all that the ELF support is being used for is > to emulate a.out. We have not yet begun to use the "good stuff". Right. I noted about 14 things that are technological advances that could be had no other way. Starting with shared libraries that finally meet the LGPL relink clause, and including getting rid of the config program, and allowing portions of the kernel to be swapped out (so long as they are not in the swap path) while not in use. Suffice to say that there are many uses for multiple data and text sections, even ignoring section attribution/coloring and non-data/text sections for things like ISA/PCMCIA card configuration. ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809200948.CAA14405>