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

[Peter A. Bigot]

On 08/14/2014 12:32 AM, Khem Raj wrote:
> On Wed, Aug 13, 2014 at 6:55 PM, Peter A. Bigot <pab at pabigot.com> wrote:
>>> EXTRA_OECONF += '${@bb.utils.contains("TUNE_FEATURES", "armv7a",
>>> "--with-cpu=generic-armv7-a", "", d)}'
>>>
>> Sorry a typo there you   need  --with-arch
>>
>>
>> OK, that works. So do we need to do the same thing for every TUNE_FEATURES
>> element that ends up changing the value of -march= in TUNE_CCARGS which ends
>> up getting passed into gcc-runtime?
> Not really but arm v6+ is an exception here due to reasons explained
> earlier. gcc as a target package is a bit
> different than rest of them since it has mind of its own when it comes
> to configuring it. It encodes certain
> defaults into its driver etc. based on the configure parameters.
> Ideally when we pass the flags via CFLAGS
> it does it for most of packages but not for gcc.

tl;dr: the proposed fix to gcc-target works for my example but I'm 
concerned it's a bandaid that doesn't address a more long-term risk.

I understand gcc-target is different.  I frame the issue as: bitbake 
(via toolchain-scripts.bbclass) ensures OE builds its applications with 
TARGET_CC_ARCH flags such as -march=FOO, but building gcc itself 
requires EXTRA_OECONF to pass different flags such as --with-arch=FOO 
which set the default behavior for the target compiler.

There are actually a bunch of these gcc configuration options:

  --with-schedule=cpu
  --with-arch=cpu
  --with-arch-32=cpu
  --with-arch-64=cpu
  --with-tune=cpu
  --with-tune-32=cpu
  --with-tune-64=cpu
  --with-abi=abi
  --with-fpu=type
  --with-float=type

all of which affect the default for the corresponding -m flags, and any 
of which may affect each other within gcc's configure script.

It sounds like the intent is that the default behavior of the target gcc 
should match what bitbake is passing via TARGET_CC_ARCH.  Of course, if 
that were guaranteed there wouldn't be any need for OE to apply 
TARGET_CC_ARCH at all, but I wouldn't suggest changing that.

My concern is that gcc-runtime invokes configure in subdirectories of 
gcc's source tree, bypassing the top-level configure where some of the 
translation from (e.g.) --with-arch=FOO to -march=FOO is done.  It then 
builds the libraries with TARGET_CC_ARCH flags appended to CC, CXX, and CPP.

What this means is that the libraries built by gcc-runtime use 
TARGET_CC_ARCH settings that don't necessarily match the target 
compiler's defaults, and that ABI conflicts can result by linking in 
those libraries when the non-default settings were absent in non-OE 
application builds.  ABI can only be "guaranteed" if every one of the 
-mFOO=BAR passed in TARGET_CC_ARCH (*or defaulted by the compiler*) has 
a corresponding -with-FOO=BAR option passed to (*or inferred by*) gcc's 
configure.

That's a pretty strong assumption to make.

It may be that this can be worked around for the specific case I raised 
by explicitly adding --with-arch=armv7-a to gcc-target's EXTRA_OECONF. I 
do have to wonder whether the same should be done for any of armv7 
armv7-m armv7-r armv7e-m armv7ve armv8-a armv8-a+crc which are other 
-march options that are armv6+, and whether there are other ABI issues 
that might be hiding now or in the future because TARGET_CC_ARCH makes 
more assumptions than gcc-target does.

The solution I propose is to rework gcc-runtime's override of CC/CXX/CPP 
so the libraries are built the same way they would be if they had been 
built during gcc-target.

 From initial attempts this won't be easy to do.  I'd be happy to keep 
trying if this worries other people, but if I'm being too picky I'll 
just suck it up and move on.

Peter