[v3] Update libstdc++ baseline on Solaris 2

[Rainer Orth]

Benjamin Kosnik <bkoz@redhat.com> writes:

>> On Linux, this is hidden by this code in src/mutex.cc:
>> 
>> // XXX GLIBCXX_ABI Deprecated
>> // gcc-4.6.0
>> // <mutex> export changes
>> #if defined(_GLIBCXX_SYMVER_GNU) && defined(PIC) \
>>     && defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE) \
>>     && defined(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT)
>> [...]
>> #define _GLIBCXX_ASM_SYMVER(cur, old, version) \
>>    asm (".symver " #cur "," #old "@@" #version);
>> 
>> _GLIBCXX_ASM_SYMVER(_ZN9__gnu_cxx10adopt_lockE, _ZSt10adopt_lock,
>> GLIBCXX_3.4.11)
[..]
> What part of the above doesn't work on Solaris? (Ie. what macros are
> defined above?) IMHO for solaris versioning to work we need to figure

_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE is undefined with Sun as, and
_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT is forcefully
defined on Solaris with every combination of tools.  As I've explained
when submitting the original symbol versioning patch, the Solaris
runtime linker ld.so.1. doesn't support that feature, even with gas and
gld in use, so you are out of luck here.  The Solaris linker maintainers
are currently opposed to adding this feature, stating that they haven't
needed anythink like this in the Solaris libraries in the past due to
careful planning (and perhaps some amount of luck :-)

> out a solution here that isn't just adding symbols. It could be adding
> in the old symbols for Solaris, but not renaming them.

Unfortunately, I've no good idea how to handle this at the moment.

> Yeah, this can be done ATM due to 4.6's pre-release state, but this
> maneuver is quite common and unless some rename or duplication strategy
> is found SONAME on solaris will diverge quickly.

... which would be a terrible mess indeed.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University