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
