Re: Symbol versions for inlined symbols

[Daniel Jacobowitz <drow@false.org>]

On Sun, Jul 31, 2005 at 03:53:42PM +0100, Mike Hearn wrote:
> 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.

The latter is the whole point.

> 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

You've completely missed the problem here, I'm afraid.  You can't use
anything like symbol scoping to do this, because the generated symbols
will end up in the application and in libC.  Besides, what if libC ends
up being a static library using libstdc++.so.5 and you want to rebuild
app?

Solving this little bit of the problem just isn't worth it.

-- 
Daniel Jacobowitz
CodeSourcery, LLC