[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Core 4



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]