This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [v3] libstdc++/52191
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Benjamin De Kosnik <bkoz at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Tue, 28 Feb 2012 21:38:12 +0100
- Subject: Re: [v3] libstdc++/52191
- References: <20120228123434.0a85ad45@adair>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Feb 28, 2012 at 12:34:34PM -0800, Benjamin De Kosnik wrote:
>
> as requested. all new symbols should be in new symbol versoning names.
> With this in, check-abi will now fail if new symbols are inadvertently
> added to previously-released versions.
>
> I'm expecting this to make solaris symbol versioning, as reported by
> check-abi, fail at first. Then we can conditionalize the failing
> symbols and add them in the newest version name on solaris, while
> keeping them in the older places for systems like linux that supported
> the functionality that added the symbols in earlier gcc releases.
> That's the plan, at least.
For 4.8, I wonder if we shouldn't run the baseline_symbols.txt files
through preprocessor as well, then we could have the TLS symbols dependent
on if _GLIBCXX_whatever_TLS_whatever macro is defined, or we could e.g.
#include "../i386-linux/baseline_symbols.txt" from i486 or x86_64/32, etc.
> 2012-02-21 Benjamin Kosnik <bkoz@redhat.com>
>
> PR libstdc++/52191
> * testsuite/util/testsuite_abi.cc (compare_symbols): Check new
> symbols added into the latest version. Mark tls entities as
> undesignated.
Jakub