[OE-core] Yocto development with C++11 threads and gcc

Peter A. Bigot pab at pabigot.com
Wed Aug 13 21:07:00 UTC 2014


On 08/11/2014 07:12 PM, Peter A. Bigot wrote:
> On 08/11/2014 02:02 PM, Peter A. Bigot wrote:
>> The program below built on the target with the MACHINE=beaglebone 
>> gcc-4.9.1 compiler from Yocto/OpenEmbedded poky master produces this 
>> error:
>>
>> beaglebone[52]$ g++ -std=c++1y -pthread test.cc && ./a.out
>> starting
>> joining
>> pure virtual method called
>> terminate called without an active exception
>> Aborted (core dumped)
>>
>> When the program is recompiled with the defines for 
>> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_X enabled as suggested at 
>> https://groups.google.com/d/msg/automatak-dnp3/Jisp_zGhd5I/ck_Cj6nO8joJ 
>> it works:
>>
>> beaglebone[53]$ g++ -std=c++1y -pthread test.cc && ./a.out
>> starting
>> joining
>> doit
>> done
>>
>> Preliminary analysis confirms that the built-ins for those defines 
>> are not being added by the compiler because it thinks the target 
>> doesn't support those operations.  Nonetheless, it doesn't use the 
>> substitutes that are obviously available.
>>
>> Can anybody recall anything about the way GCC is built under OE that 
>> would explain this?
>
> Not an OE problem.  See: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
>
> I'm testing a patch locally and awaiting GCC maintainer comment before 
> proposing it for OE.

The GNU folks objected to the workaround and suggested that the behavior 
is evidence that libstdc++ was not built with the same ABI flags as the 
compiler uses by default.

I built the release version of gcc 4.9.1 on the beaglebone and confirmed 
that it works fine.

This is indeed an OE-Core bug.

I've just sent a series of cleanup patches to gcc that may make it 
easier to detect differences.  I've spent some time changing the 
"obvious" things and have been unable to figure out where the 
compilation is going wrong.  I'm hoping somebody else can help out; as 
C++11 becomes more prevalent the workaround recommended on stackoverflow 
and other sites will continue to propagate, and it's not the right solution.

Peter




More information about the Openembedded-core mailing list