Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Peter A. Bigot" <pab@pabigot.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: Yocto development with C++11 threads and gcc
Date: Thu, 14 Aug 2014 22:40:29 +0100	[thread overview]
Message-ID: <1408052429.21596.2.camel@ted> (raw)
In-Reply-To: <53EC7E27.6010507@pabigot.com>

On Thu, 2014-08-14 at 04:15 -0500, Peter A. Bigot wrote:
> 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.

Its a valid concern, I just don't think anyone else has run into the
kinds of issues you're seeing :/. We don't want to diverge too far from
upstream gcc, equally, we need a working compiler...

Cheers,

Richard



  reply	other threads:[~2014-08-14 21:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-11 19:02 Yocto development with C++11 threads and gcc Peter A. Bigot
2014-08-12  0:12 ` Peter A. Bigot
2014-08-13 21:07   ` Peter A. Bigot
2014-08-13 21:18 ` Khem Raj
2014-08-13 21:23   ` Peter A. Bigot
2014-08-13 21:36     ` Peter A. Bigot
2014-08-13 22:05       ` Khem Raj
2014-08-13 23:23         ` Peter A. Bigot
2014-08-14  0:49           ` Khem Raj
2014-08-14  1:55             ` Peter A. Bigot
2014-08-14  5:32               ` Khem Raj
2014-08-14  9:15                 ` Peter A. Bigot
2014-08-14 21:40                   ` Richard Purdie [this message]
2014-08-14 22:00                     ` Peter A. Bigot
2014-08-14 22:11                       ` Khem Raj
2014-08-14 22:07                   ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1408052429.21596.2.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=pab@pabigot.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox