This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] Update libstdc++ baseline on Solaris 2
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: libstdc++ at gcc dot gnu dot org, Benjamin Kosnik <bkoz at redhat dot com>
- Date: Wed, 01 Dec 2010 14:58:08 +0100
- Subject: Re: [v3] Update libstdc++ baseline on Solaris 2
- References: <yddeia458vq.fsf@manam.CeBiTec.Uni-Bielefeld.DE> <4CF3F292.900@oracle.com>
Hi Paolo,
> as usual for this kind of changes, which are supposed to affect only
> Solaris, assuming you also regtested on x86_64-linux, no objections from
the patch was bootstrapped without regressions on
x86_64-unknown-linux-gnu. Checked in now.
> me. I only want to add..
>> Finally, std::system_error::system_error(std::error_code) was probably
>> removed by this patch:
>>
>> 2010-09-16 Paolo Carlini <paolo.carlini@oracle.com>
>>
>> * include/std/system_error (system_error::system_error(error_code),
>> system_error(error_code, const string&), system_error(int, const
>> error_category&), system_error(int, const error_category&,
>> const string&)): Fix for what() to return the NBTS recommended in
>> the Note in 19.5.6.2/14.
>>
> that the symbol was evidently exported inadvertently, only because a
> regular expression used to match: the symbol doesn't belong to an extern
> template instantiation neither its code is defined in the .cc file, is
> defined inline. Thus, as far as I can see we are not risking any
> breakage: before the change user code could not possibly have referenced
> the library symbol.
Ok, thanks for the explanation. Still, the use of glob patterns in the
version maps bears the risk that stuff can slip through the cracks, like
being added in one version and being removed again later if the
baselines are never updated.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University