Fedora Core 4

[Arjan van de Ven]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050115/19c3acb1/attachment-0002.bin