Date: Mon, 20 Feb 1995 13:00:10 -0700 From: Nate Williams <nate@trout.sri.MT.net> To: "Andrey A. Chernov, Black Mage" <ache@astral.msk.su> Cc: current@freefall.cdrom.com Subject: Re: libcompat and shlib conflict Message-ID: <199502202000.NAA07147@trout.sri.MT.net> In-Reply-To: "Andrey A. Chernov, Black Mage" <ache@astral.msk.su> "Re: libcompat and shlib conflict" (Feb 20, 10:37pm)
next in thread | previous in thread | raw e-mail | index | archive | help
> >A program compiled with a static libcompat as opposed to a dynamic > >libcompat is more likely to correctly match another platforms ABI > >in any case. Not only are we not guaranteed that the external > >globals linked into your program and referenced by the libcompat > >routines will be the same on another platform (causing their shared > >libcompat to fail), but the cruft in libcompat is likely as not > >going to be different from vendor to vendor anyway. > > If you look in, you can see, that other platforms do just the same thing, > only one condition needs to be present: regerror module itself > must be placed before regex module, as already done. You didn't understand what Terry was saying. There is no guarantee that the same modules exist in a different vendor's libcompat. > >The cost of the cruft should be bourne by the crufty program. > > Too many crufty pgms in the world. You don't have enough power > to teach whole world which functions to use. So, does that mean we shouldn't at least try? We continue to provide libcompat, just not a shared version. This means that binaries compiled with -lcompat will be *more* portable across multiple vendors and releases than version relying on the shlib providing the old interfaces. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502202000.NAA07147>