From: "Daniel Mack" <daniel@zonque.org>
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] Add -fcommon to BUILD_CFLAGS to a number of recipes
Date: Sun, 3 May 2020 12:55:01 +0200 [thread overview]
Message-ID: <527b9801-2d77-e337-b799-4f2a14e6aa62@zonque.org> (raw)
In-Reply-To: <e9f18f5d8df6e34e0cf7a81f2860b62a795623f4.camel@linuxfoundation.org>
Hi Richard,
Thanks a lot for checking!
On 5/3/20 12:04 PM, Richard Purdie wrote:
> On Sun, 2020-05-03 at 10:26 +0200, Daniel Mack wrote:
>> When building on a gcc 10 enabled host distribution (such as Fedora
>> 32),
>> a number of recipies need explicit treatment to enable '-fcommon' in
>> BUILD_CFLAGS. There might be more of those fixes needed.
>>
>> Commit 46827b8616 ("recipes: Use -fcommon explicitly") already
>> addressed
>> that for some places, but tweaking CFLAGS doesn't seem to suffice.
>
> Thanks for this, its definitely something we need to fid.
>
> The work in the previous patch was fixing gcc 10 target builds, not
> host. Your patch changes CFLAGS to BUILD_CFLAGS in places which means
> when we upgrade to gcc 10 things will break.
Ah, I wasn't aware that cross-compilation is ready for gcc 10 yet. Okay,
that makes sense.
> Basically:
>
> CFLAGS should cover build and target
> TARGET_CFLAGS should cover target builds (gcc cross as gcc 10)
> BUILD_CFLAGS should cover host tools (gcc 10 on the host)
>
> so the correct place should be CFLAGS which should cover target and
> build (host).
I assumed that, yes, but at least for the recipes I addressed in my
patch, that doesn't cut it.
That said, there is also another patch needed for syslinux that doesn't
seem to allow injecting CFLAGS externally.
> Its possible that some recipes build native and target components in
> which case they might use CFLAGS and BUILD_CFLAGS. Based on what you
> say in the commit message, there might be a bug and we might be missing
> injecting CFLAGS into BUILD_CFLAGS.
>
> I think this is going to need a little more investigation to get it
> right.
Alright. I'm happy to respin my patch or test alternative approaches.
After all, gcc 10 will have more exposure very soon with more
distributions are picking it up as default compiler.
Thanks,
Daniel
next prev parent reply other threads:[~2020-05-03 10:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-03 8:26 [PATCH] Add -fcommon to BUILD_CFLAGS to a number of recipes daniel
2020-05-03 8:32 ` ✗ patchtest: failure for " Patchwork
2020-05-03 10:04 ` [OE-core] [PATCH] " Richard Purdie
2020-05-03 10:55 ` Daniel Mack [this message]
2020-05-03 20:00 ` Adrian Bunk
[not found] <20200503080730.3686063-1-daniel@zonque.org>
2020-05-03 17:39 ` Khem Raj
2020-05-03 19:21 ` [OE-core] " Andre McCurdy
2020-05-04 17:46 ` Khem Raj
2020-05-06 7:22 ` Adrian Bunk
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=527b9801-2d77-e337-b799-4f2a14e6aa62@zonque.org \
--to=daniel@zonque.org \
--cc=openembedded-core@lists.openembedded.org \
/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