On Sat, 15 Jan 2005 16:10:56 +0100, Arjan van de Ven wrote: > FORTIFY_SOURCE is by far not the only thing that might make your > binaries require a "new" glibc. If you want to run against an old glibc, > you should build against such an old glibc. No, there are plenty of things, it's an annoying policy which we have a lot of code to hack around (see apbuild). > 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. > 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) Obviously if you actually require new symbols or features (like ELF TLS) then you'll need a newer glibc, but there's a big difference between consciously depending on a new version and accidentally getting a dependency on it you probably don't need. > If you don't want that.. don't do that then. 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. thanks -mike
