Re: [v3] Update Solaris baselines for GCC 4.7

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

Jakub Jelinek <jakub@redhat.com> writes:

> On Fri, Jan 27, 2012 at 05:54:56PM +0100, Rainer Orth wrote:
>> Paolo Carlini <paolo.carlini@oracle.com> writes:
>> 
>> > On 01/27/2012 05:46 PM, Rainer Orth wrote:
>> >> I'd even argue that abi_check should flag all additions to released
>> >> versions as a hard error.
>> > Again, agreed. As a matter of fact, I'm pretty sure we do that already, I'm
>> > pretty sure Benjamin tightened abi_check in the light of that problem we
>> > had in 2005.
>> 
>> I doubt that, otherwise the additions to versions already released
>> should have been flagged as such on Solaris, but abi_check suggests they
>> are benign.
>
> If you mean
> TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11                                                                                                            
> TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11                                                                                                        
> then those symbols were really added in 3.4.11, but I haven't added them
> (intentionally) to the baseline symbols, since then anybody configuring
> without working TLS would get hard make check failures.

Those were among them, but I can't currently check the full list since a
build is just running.  I have a similar issue on Solaris 8 and 9,
already mentioned in my (tentative) patch submission:

	http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01163.html

Depending on the toolchain used (Sun as which doesn't support TLS, or
GNU as which does), you get either emutls or native TLS related symbol.
Omitting either from the baselines is certainly an option, as would be
having separate baselines, though certainly ugly.

Could you please also have a look at the questions raised in the patch
submission?  

I think we should avoid adding to GLIBCXX_3.4.5, 3.4.11, and 3.4.15 on
Solaris, avoiding the old mistake on the Linux side, even if that means
having a separate (or preprocessed) gnu.ver for that purpose.

Thanks.
	Rainer

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