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

Re: Fedora Core 4

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

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