Re: [v3] Provide Solaris 2 libstdc++ baseline files

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

Hi Paolo,

> [skipping the detailed analysis, let me know if there is something we
> should do because it affects non-Solaris systems]

I think there are a two open questions:

* Do you have a suggestion for the source of the two differently mangled
  instances of std::system_error::system_error(std::error_code) on
  Solaris 11/x86 (but not SPARC)?

* What to do with TLS symbols (std::__once_call and
  std::__once_callable)?  When using pvs on Solaris, I cannot easily
  exclude them from the the baseline_symbols.txt files, but it might be
  appropriate to include them on other systems that use readelf, too,
  since they effectively form part of the ABI.

>> Ok for mainline after that testing has passed?
>>   
> Sure. Under the usual preconditions that the Changes you are proposing
> have no effect for any other target, the approval is essentially obvious.

I'm pretty certain there can be no ill effect on other platforms.
AFAIK, pvs is only available on Solaris, so no other platform will try
to use it.  The other changes to configure.host and the various Solaris
baselines cannot affect anything else, so this is totally safe.
Bootstraps are running now, and I'll commit the files once they are
completed.

>> And what about updating the baselines in the future if new symbols are
>> added?  I suppose I can do that myself without explicit approval?
>>   
> I'm not sure to follow the reasoning here: as we mean it,  a baseline,
> by definition, *never* changes, it's sort-of a concrete surrogate of an
> ABI which we don't want to break. Then, given the baseline, we want to
> check that successive minor versions of the library only add symbols,
> versioned at the corresponding minor version, and never remove symbols
> or add symbols at previous (older) minor versions. Indeed, this is what
> abi_check does. Thus, I'm not sure to follow your reasoning... Granted,
> something is special here about adding the baselines *now*, because
> normally the baselines we have correspond to the gcc3.4.0 symbols, but
> anyway, the general rule about the correct way of moving forward without
> breaking old executables should stay the same, in particular no changes
> to the baselines, etc.

I'm a bit worried about this procedure because it would allow to add a
symbol after 3.4.0 and later remove it again without being noticed.  I'd
expect the baselines to be regenerated just before minor releases to
guard against exactly such a situation, of course making certain at this
time that they are a strict superset of the previous release's baseline.

	Rainer

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