RFH: Symbol versions for __aeabi symbols
Mark Mitchell
mark@codesourcery.com
Tue Jul 8 15:56:00 GMT 2008
Paolo Carlini wrote:
> I would suggest double checking with Benjamin
Benjamin, I've explicitly added you to the CC: at Paolo's suggestion.
>> 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.
OK, that makes sense. I wasn't quite sure what the tradeoffs were.
Obviously, there are not presently any binaries linked against these
symbols, since they aren't exported, so exporting the symbols with any
version cannot break existing binaries. But, I guess that if we added
them with an old version, then new binaries might not get a very obvious
error when they were linked against an old libsupc++.
I'll add a CXXABI_1.3.3 version.
>> 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...
OK, I'll add them, test on both x86 and ARM Linux, and submit.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
More information about the Libstdc++
mailing list