Re: Symbol versions for inlined symbols

[Mike Hearn <mike@plan99.net>]

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