Fedora Core 4

[Mike Hearn]

On Sat, 15 Jan 2005 19:47:54 +0100, Arjan van de Ven wrote:
> 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.

Right.

> it's actually very useful

Well, there are two ways to use it. If you use it to tag symbols with a
single version specifying when they were introduced, this is useful for
lots of reasons. For instance RPM and the linker can figure out minor
versions.

The problems start when you have one symbol with multiple versions: this
is worse than just renaming the symbol because while old *binaries*
continue to work, if you then compile the same sources on a newer system
they get the new semantics automatically which could break them.

Eg take the example of regexec, which has a new overloaded version of
GLIBC_2.3.4 - the new version was introduced because now if you specify
unknown eflags it returns with error whereas before I guess it didn't.

That keeps old binaries working, but what if you then take old code
and compile it on a newer system? Well now the code doesn't get the
semantics it expects and breaks.

The right way to do this IMHO is to just introduce a regexec2 function and
then have the headers select the right version at compile time, where the
"right" version is based on what version of glibc the program targets as
defined by some macro, eg:

#define TARGET_GLIBC_MINOR 3
#define TARGET_GLIBC_MICRO 4
// or you could just have an incrementing integer

#include <regex.h>

now your code is rewritten to use regexec2 and the new behaviour. The
changes between each version should be clearly documented so people can
read the changes and say "hmm, I seem to remember writing code that did
that" and go back and check their source. Meanwhile code is upgraded to
the new semantics in a controlled fashion and it's still easy to build
against older versions if you don't need or want the new versions.

It's also more portable.

Likewise it'd be nice if things like thread-local locales were opt-in,
really desktop applications don't need this feature at all ...

> _FORTIFY_SOURCE needs to be specified to be active, so this side of your
> worries should not be a problem; 

OK, cool. It'd be even better if the __stack_smash symbol[s] (I guess this
is what glibc is providing) could be compiled into binaries during the
transition period. Of course for distro provided binaries you can have it
dynamically linked and one day when most people have upgraded statically
linking it wouldn't be needed any more for anybody.

>                                  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.

Yep I know, been there, done that :) It's a pain. As time goes on I hope
to argue that we as a community should do this more how Windows does it,
using versioned headers so you can know with confidence exactly what
the dependencies of any given build will be.

thanks -mike