This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] Update Solaris baselines for GCC 4.7
Jakub Jelinek <jakub@redhat.com> writes:
> On Mon, Jan 23, 2012 at 07:31:55PM +0100, Rainer Orth wrote:
>> * There's quite a number of additions to 3.4.11:
>
> Probably Solaris didn't have _GLIBCXX_HAS_GTHREADS support
> before and now does?
Right, it didn't on Solaris 8 and 9 in 4.6, but does now. It seems the
test has changed, but I didn't yet investigate in detail.
> config/abi/pre/*.ver isn't currently conditionalized in any way,
> so I don't see an easy way to move these to GLIBCXX_3.4.17 just
> for Solaris and not for others.
It could be done along the same line as
#ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
is used. gnu.ver is already preprocessed for Solaris, so one could add
to that. Ugly but certainly better than breaking versioning. OTOH,
that would mean that the symbols are in 3.4.11 in a Solaris 10+-built
libstdc++, but in 3.4.17 on a Solaris 8-built one...
>> Apart from that, baselines with Sun as (emutls) and GNU as (native TLS)
>> differ on Solaris 8:
>>
>> --- baseline_symbols.txt 2012-01-23 19:01:03.590486000 +0100
>> +++ baseline_symbols.txt.s8g 2012-01-23 19:03:38.063402000 +0100
>> @@ -2176,0 +2177 @@
>> +FUNC:_ZSt16__get_once_mutexv@@GLIBCXX_3.4.12
>> @@ -2209,0 +2211 @@
>> +FUNC:_ZSt23__get_once_functor_lockv@@GLIBCXX_3.4.11
>> @@ -2212,0 +2215 @@
>> +FUNC:_ZSt27__set_once_functor_lock_ptrPSt11unique_lockISt5mutexE@@GLIBCXX_3.4.12
>> @@ -2649,0 +2653 @@
>> +OBJECT:16:_ZSt14__once_functor@@GLIBCXX_3.4.11
>> @@ -2715,2 +2718,0 @@
>> -OBJECT:16:__emutls_v._ZSt11__once_call@@GLIBCXX_3.4.15
>> -OBJECT:16:__emutls_v._ZSt15__once_callable@@GLIBCXX_3.4.15
>>
>> This hasn't happened before. While the additions with gas are ok, the
>> removals are not.
>
> libstdc++ with and without TLS support are simply not ABI compatible.
Obviously. Given that the only Solaris configurations lacking native
TLS support are old Solaris 8 and 9 toolchains with Sun as, one could
omit the TLS related in those baselines, just as you did for Linux.
Adding a second set of baselines (and the infrastructure to deal with
them) is probably not worth the effort.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University