This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: RFH: Symbol versions for __aeabi symbols
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Mark Mitchell <mark at codesourcery dot com>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 8 Jul 2008 06:05:55 -0500 (CDT)
- Subject: Re: RFH: Symbol versions for __aeabi symbols
- Accept-language: en-US
- References: <48727C24.1080704@codesourcery.com>
Hi Mark,
I would suggest double checking with Benjamin, he started the whole versioning business...Anyway...
> 1. What version should I use?
>
> In config/abi/pre/gnu.ver, it looks like the non-ARM variants
> are exported with version CXXABI_1.3. Should I just put the ARM
> variants there too? Or add them to CXXABI_1.3.2, which is the latest
> version? Or create a new CXXABI_1.3.3 version?
Yes, normally we create a new version in such cases. The only situation in which we have an optionis when we are between releases and recently created a new version after the release. Then we can keep adding provided we know nobody is releasing from snapshots or any dangerous situation like that.
Otherwise, seems quite obvious to me that the only safe, general approach when there are already around releases with CXXABI_1.3.2, is opening a new CXXABI_1.3.3 for the new symbols.
> 2. Is it bad to add them unconditionally, even though the
> symbols are only defined on ARM platforms? Or do I need to somehow
> conditionalize on being on an ARM system? And, if so, how do I do that?
This seems more subtle but I cannot imagine any problem with just exporting the symbols, provided of course are only defined on ARM... Ah now I see the real issue: ideally we would like to stay at 1.3.2 for all the other targets and bump to 1.3.3 *only* for ARM... I don't think we can really do that...
Paolo.