Thanks for the reply Jon,
It would be nice to be able to build gcc-4.7.2 without maintaining
binary compatibility with previous versions of gcc-4.7 since, for
example, I like to recompile the whole codebase when switching to a
newer version of a compiler just to eliminate any uncertainty arising
from possible binary ABI compatibility issues. Something like
--no-legacy-abi configure switch.
Maxim
On 2 October 2012 11:40, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote:
> On 2 October 2012 10:28, Maxim Yegorushkin wrote:
>> Hi gcc-help,
>>
>> I've just switched from gcc-4.7.1 to gcc-4.7.2 and am not getting new
>> warning when I link my project:
>>
>> /usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../x86_64-unknown-linux-gnu/bin/ld:
>> warning: while linking
>> /home/max/otsquant/build/Linux-x86_64-64.g++-debug/test/trade_scheduler_test:
>> symbol 'std::__future_base::_Async_state_common::~_Async_state_common()'
>> defined in multiple places (possible ODR violation):
>> /usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/future:1431
>> from /home/max/otsquant/build/Linux-x86_64-64.g++-debug/obj-mt/trade_scheduler/optimizer.o
>> ../../../../gcc-4.7.2-src/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:89
>> from /usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib64/libstdc++.so
>>
>> Quick grep for "~_Async_state_common" reveals:
>>
>> class __future_base::_Async_state_common : public __future_base::_State_base
>> {
>> protected:
>> #ifdef _GLIBCXX_ASYNC_ABI_COMPAT
>> ~_Async_state_common();
>> #else
>> ~_Async_state_common() = default;
>> #endif
>>
>> I could not find any documentation for _GLIBCXX_ASYNC_ABI_COMPAT
>> macro. What is it for, should I define it to avoid ODR warnings?
>
> Hi Max,
>
> No, it's not for users, it's an internal implementation detail,
> defined by src/c++11/compatibility-thread-c++0x.cc when building the
> library:
> http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/c%2B%2B11/compatibility-thread-c%2B%2B0x.cc?view=markup&pathrev=190685
>
> I needed to change the definition of the destructor, but the old
> definition was exported from the library and existing code built with
> GCC 4.7.1 might refer to that symbol, so when the library is built the
> old definition is defined so that code built with older versions of
> GCC can still link to the library.
>
> I didn't test the change with Gold, but I think the warning is
> harmless. I'll investigate asap.
