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.