[v3] Provide Solaris 2 libstdc++ baseline files

[Rainer Orth]

Marc Glisse <marc.glisse@inria.fr> writes:

> On Tue, 28 Sep 2010, Rainer Orth wrote:
>
>> * For Solaris 11, there's a strange difference: in both 32 and 64-bit
>>  cases, I get
>>
>> --- sparc-sun-solaris2.11/baseline_symbols.txt  2010-09-22 11:55:52.651907686 +0
>> 200
>> +++ i386-pc-solaris2.11/baseline_symbols.txt    2010-09-22 11:55:52.604358688 +0
>> 200
>> @@ -1235,6 +1235,7 @@
>> FUNC:_ZNSt12system_errorC1ESt10error_code
>> +FUNC:_ZNSt12system_errorC2ESt10error_code
>>
>>  Both functions demangle as
>>  std::system_error::system_error(std::error_code); I've no idea why
>>  there's an additional one on i386.
>
> Generating two versions of the constructor is what g++ usually does, as can
> be seen on any trivial example:
> struct A{A();}; A::A(){}
>
> (although now on several platforms the 2 names will actually point to the
> same address)

Indeed, confirmed by compiling that example on both Solaris 11/SPARC and x86.

> I find it more surprising that one of them is missing on sparc. And since
> you get this with both Sun and GNU linkers, it doesn't seem like it can
> have removed the unused one.

Right, there was something really fishy going on: the slightly older
baselines I've used so far (created with the current extract_symvers
script) show this anomaly, while the current ones (created with
pvs-based extract_symvers) do not ;-)  Oh well, I'll re-compare the
baselines before checkin to make sure the remaining differences seem
sane.

Based on Paolo's description, I'll probably go for a slightly simpler
scheme to store the Solaris 2 baselines:

      solaris2.8
      solaris2.8/sparcv9
      solaris2.10
      solaris2.10/amd64
      solaris2.10/sparcv9

The solaris2.8 directories will be used for Solaris 8 and 9, both SPARC
and x86, with 64-bit SPARC included as well (AMD64 support only appeared
in Solaris 10).

I need a separate solaris2.10 directory for Solaris 10 and 11 since
between Solaris 9 and 10, the ISO C99 math functions were added to libm
and so the replacement functions don't any longer appear in
libstdc++.so.

Otherwise every other change seems to be an addition as expected.

	Rainer

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