On Sun, 31 Jul 2005 00:57:49 -0400, Daniel Jacobowitz wrote: > You may wish to read the proceedings from this year's GCC summit, where > another solution was presented by some gentlemen from Intel. For various > reasons, symbol versioning is not a useful solution to this problem.
I hadn't seen that, thanks. It's an interesting approach but a bit confusing to somebody like me who doesn't use C++ very often: it sounded from their writeup like you'd have to modify application code, and then in other parts it sounded like actually only the libstdc++ headers would need to be modified and apps would do the right thing transparently. >From my perspective the most convenient solution would be a way to modify ELF symbol scoping (which is what symbol versioning does, in a complicated sort of way). Instead of starting lookup for a symbol in libC from app, going on through libstdc++.so.5, libA, libB, libC, libstdc++.so.6, libD: app libstdc++.so.5 libA, libB, libC, libstdc++.so.6 libD something more similar to Windows where a symbol lookup starting in libC checks libC, libstdc++.so.6, libD, app, libstdc++,so.5, libA, libB would work. That way, the GLOBAL WEAK symbols in the std namespace would always resolve to what you'd intuitively expect: the dependencies of that object. ELF compatibility would mostly be preserved as symbols could still be resolved to the parent and other objects in the image, but the chance of cross-wiring would be reduced. I think this is what the DT_1_GROUP flag is supposed to do, but for some reason it was never implemented in the glibc linker. Does anybody know why? Last time I talked about this with Michael Meeks at Novell, he seemed to think the semantics of the DT_1_GROUP flag would mess up C++ exception handling, which relies on the current ordering. Is that so? Oh, final thing - the GCC summit paper made it sound like only rare proprietary apps need the ability to mix multiple libstdc++ versions in the same image, but it's a very common thing to do for open source programs too: specifically, games. Games are why I'm asking, actually :) We already have nasty workarounds for this issue in place for NetPanzer, Lincity and a few other projects that distribute binaries and may be linked against other C++ libraries already on the system. The classic example is "C++ Game -> SDL -> SDL_audio -> libArts (for KDE audio) -> mismatched libstdc++ version -> crash in std::string". thanks -mike
