On Sat, 2005-01-15 at 18:05 +0000, Mike Hearn wrote: > . > > > Example: NPTL threads. > > Code which actually depends on NPTL vs LinuxThreads needs at > minimum configure-time checks for that, or more likely just compliance > fixes. It's also possible to check for it at runtime like Wine does. what I meant was that when you *compile* to a nptl glibc, you actually will not run on and older (linuxthreads) glibc simply because you use symbol versions from the new glibc. > > > There are countless other examples of things that make your app require > > a newer glibc *IF* you build against a new glibc. > > Thread-local locales are the only one that spring to mind, and that's > easily suppressed. And symbol overloading of course. You can work around > that too, symbol overloading like glibc does is broken anyway imho (though > marking symbols with one version tag isn't) it's actually very useful > Building on an old glibc really means "build on an old distro" and that's > unacceptable. Fortunately if you have to define _FORTIFY_SOURCE then it's > OK, that can be selectively disabled. Or alternatively the symbols that > are currently in glibc could be in libgcc or optionally statically > linked, which makes checked binaries a lot easier to distribute. _FORTIFY_SOURCE needs to be specified to be active, so this side of your worries should not be a problem; it's just that your general assumption about compatibility is somewhat problematic. In linux generally there is only unidirectional compatibility; eg old stuff keeps running on newer distributions, but the other way around is mostly if not entirely ignored.
Attachment:
signature.asc
Description: This is a digitally signed message part
