From: Mike Crowe <mac@mcrowe.com>
To: Khem Raj <raj.khem@gmail.com>, Chris Larson <clarson@kergoth.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: export TARGET_LDFLAGS and native sstate
Date: Wed, 16 Apr 2014 10:43:45 +0100 [thread overview]
Message-ID: <20140416094345.GA8872@mcrowe.com> (raw)
In-Reply-To: <CAMKF1spaiP8bkNxnSHqUs4tg6=gfZqR8fZaTrDn-N=s1iSDLkw@mail.gmail.com>
On Monday 07 April 2014 at 12:35:44 -0700, Khem Raj wrote:
> -Khem
> On Apr 7, 2014 5:53 AM, "Mike Crowe" <mac@mcrowe.com> wrote:
> >
> > We're building for both ARM and MIPS-based MACHINEs in a single source
> > tree. This seems to result in us compiling (or luckily most of the time
> > resurrecting from sstate-cache) two different versions of all -native
> > packages due to different base hashes.
> >
> > It seems that this difference in base hashes is due to the exported
> > variable TARGET_LDFLAGS being different between the two CPUs:
> >
> > < export TARGET_LDFLAGS="-Wl,-O1 -Wl,--as-needed"
> > ---
> > > export TARGET_LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
> >
> > which in turn is because TARGET_LINK_HASH_STYLE is explicitly set to
> "sysv"
> > on MIPS but allowed to be "gnu" on everything else.
> >
> > Every time I switch back and forth between building ARM-based and
> > MIPS-based machines the do_populate_sysroot_setscene tasks run for each
> > required -native recipe.
> >
> > If I modify native.bbclass to do:
> >
> > TARGET_LDFLAGS = "${BUILD_LDFLAGS}"
>
> this is reasonable to do
I've submitted a patch that does this in
<1397640696-21281-1-git-send-email-mac@mcrowe.com> . The patch also does
the same thing to TARGET_CFLAGS, TARGET_CXXFLAGS and TARGET_CPPFLAGS. I'll
let the experts decided whether this is suitable for Daisy or not.
We're currently running our build with TARGET_LDFLAGS not exported and
haven't noticed any problems yet. I can submit a patch that does this but
I'd feel bound to also stop exporting TARGET_CFLAGS, TARGET_CXXFLAGS and
TARGET_CPPFLAGS for consistency though. Such a patch would definitely not
be suitable for Daisy.
Either (or both) patches solve my problem with task hashes.
Thanks.
Mike.
prev parent reply other threads:[~2014-04-16 9:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-07 15:53 export TARGET_LDFLAGS and native sstate Mike Crowe
2014-04-07 16:17 ` Chris Larson
2014-04-07 16:49 ` Mike Crowe
2014-04-10 16:15 ` Mike Crowe
2014-04-10 17:36 ` Chris Larson
2014-04-10 17:38 ` Denys Dmytriyenko
2014-04-07 19:35 ` Khem Raj
2014-04-16 9:43 ` Mike Crowe [this message]
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=20140416094345.GA8872@mcrowe.com \
--to=mac@mcrowe.com \
--cc=clarson@kergoth.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.