Re: [v3] Update Solaris baselines for GCC 4.7

[Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>]

Paolo Carlini <paolo.carlini@oracle.com> writes:

> On 01/23/2012 07:31 PM, Rainer Orth wrote:
>> * I noticed several new symbols being placed into GLIBCXX_3.4.5, which
>>    also happens with gld and thus isn't an issue with Sun ld versioning
>>    support.  Adding to an old version is not supposed to happen and must
>>    be fixed.
>>
>> +FUNC:_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5
>> +FUNC:_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5
> I don't think this is a new issue, I see it in 4.6 branch and even in 4.5
> branch. At some point we had a problem which Jakub patched (thus the *XX
> variants), the actual story is longish but is not new, I'm not sure you are
> interested in thegory details.

Perhaps you have a pointer?

>> * There's quite a number of additions to 3.4.11:
>>
>> +FUNC:_ZNKSt10lock_error4whatEv@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt18condition_variable10notify_allEv@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt18condition_variable10notify_oneEv@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt18condition_variableC1Ev@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt18condition_variableC2Ev@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt18condition_variableD1Ev@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt18condition_variableD2Ev@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt22condition_variable_anyC1Ev@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt22condition_variable_anyC2Ev@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt22condition_variable_anyD1Ev@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt22condition_variable_anyD2Ev@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt6thread4joinEv@@GLIBCXX_3.4.11
>> +FUNC:_ZNSt6thread6detachEv@@GLIBCXX_3.4.11
>> +FUNC:__once_proxy@@GLIBCXX_3.4.11
>> +OBJECT:12:_ZTISt10lock_error@@GLIBCXX_3.4.11
>> +OBJECT:15:_ZTSSt10lock_error@@GLIBCXX_3.4.11
>> +OBJECT:20:_ZTVSt10lock_error@@GLIBCXX_3.4.11
>> +OBJECT:24:_ZTISt10lock_error@@GLIBCXX_3.4.11
>> +OBJECT:40:_ZTVSt10lock_error@@GLIBCXX_3.4.11
> This, I don't see why you considered it some sort of "problem"?!? Yes we
> started exporting some additional symbols, in 3.4.11, I can confirm that.

Adding new symbols to an old version is fundamentally wrong IMO:
consider you have some libstdc++.so from some older gcc release that
includes anything up to GLIBCXX_3.4.11.  Now you compile and link some
new executable with g++ 4.7.0 and the new libstdc++.so which contains
those new symbols in GLIBCXX_3.4.11.  That executable only uses symbols
from that version, including some of those added after GLIBCXX_3.4.11
originally shipped, nothing newer.  When you try to run it on the older
system, ld.so.1 detects that the libstdc++.so there provides all
versions required by the executable, concludes that it is safe to run
it, starts it, and later there's a reference to those new symbols which
of course aren't present: crash/bang!  This is exactly what symbol
versioning is supposed to avoid.  It is intended to allow the runtime
linker to detect up front if it is safe to run an executable because
its dependencies are present.

Old versions *must* be frozen once they have been released, otherwise
this whole symbol versioning stuff is moot.

	Rainer

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