Patchwork native.bbclass: Override TARGET_ flags too

login
register
mail settings
Submitter Mike Crowe
Date April 16, 2014, 9:31 a.m.
Message ID <1397640696-21281-1-git-send-email-mac@mcrowe.com>
Download mbox | patch
Permalink /patch/70619/
State New
Headers show

Comments

Mike Crowe - April 16, 2014, 9:31 a.m.
TARGET_LDFLAGS is currently defined in bitbake.conf to contain
${TARGET_LINK_HASH_STYLE} which differs between MIPS and other
targets. Since TARGET_LDFLAGS is an exported variable it affects the hash
of every shell task even if it is not used.

We don't want native recipe tasks to have different hashes purely because
they happen to have been built in order to satisfy dependencies for
different MACHINEs since this causes lots of churn in the native sysroot
when switching between MACHINEs.

Making native.bbclass override TARGET_LDFLAGS to use BUILD_LDFLAGS ensures
consistent hashes and is a sensible thing to be doing anyway.

Although they don't appear to have the same detrimental affect on task
hashes TARGET_CPPFLAGS, TARGET_CFLAGS and TARGET_CXXFLAGS should be
overridden too.

Signed-off-by: Mike Crowe <mac@mcrowe.com>
---
 meta/classes/native.bbclass | 4 ++++
 1 file changed, 4 insertions(+)
Paul Eggleton - April 16, 2014, 9:49 a.m.
On Wednesday 16 April 2014 10:31:36 Mike Crowe wrote:
> TARGET_LDFLAGS is currently defined in bitbake.conf to contain
> ${TARGET_LINK_HASH_STYLE} which differs between MIPS and other
> targets. Since TARGET_LDFLAGS is an exported variable it affects the hash
> of every shell task even if it is not used.
> 
> We don't want native recipe tasks to have different hashes purely because
> they happen to have been built in order to satisfy dependencies for
> different MACHINEs since this causes lots of churn in the native sysroot
> when switching between MACHINEs.
> 
> Making native.bbclass override TARGET_LDFLAGS to use BUILD_LDFLAGS ensures
> consistent hashes and is a sensible thing to be doing anyway.

Just to be clear, for a native recipe how is TARGET_LDFLAGS entering the 
signatures? AIUI there ought to be indirection such that LDFLAGS is used and 
that is set from BUILD_LDFLAGS for a native recipe rather than TARGET_LDFLAGS.

Cheers,
Paul
Mike Crowe - April 16, 2014, 9:53 a.m.
On Wednesday 16 April 2014 at 10:49:48 +0100, Paul Eggleton wrote:
> On Wednesday 16 April 2014 10:31:36 Mike Crowe wrote:
> > TARGET_LDFLAGS is currently defined in bitbake.conf to contain
> > ${TARGET_LINK_HASH_STYLE} which differs between MIPS and other
> > targets. Since TARGET_LDFLAGS is an exported variable it affects the hash
> > of every shell task even if it is not used.
> > 
> > We don't want native recipe tasks to have different hashes purely because
> > they happen to have been built in order to satisfy dependencies for
> > different MACHINEs since this causes lots of churn in the native sysroot
> > when switching between MACHINEs.
> > 
> > Making native.bbclass override TARGET_LDFLAGS to use BUILD_LDFLAGS ensures
> > consistent hashes and is a sensible thing to be doing anyway.
> 
> Just to be clear, for a native recipe how is TARGET_LDFLAGS entering the 
> signatures? AIUI there ought to be indirection such that LDFLAGS is used and 
> that is set from BUILD_LDFLAGS for a native recipe rather than
> TARGET_LDFLAGS.

Because TARGET_LDFLAGS is an exported variable. LDFLAGS is set from
TARGET_LDFLAGS but (prior to this patch) only LDFLAGS is set to
BUILD_LDFLAGS; TARGET_LDFLAGS remains unchanged.

See thread "export TARGET_LDFLAGS and native sstate"
<20140407155333.GA19351@mcrowe.com> .

Should I improve the commit message?

Thanks.

Mike.
Paul Eggleton - April 16, 2014, 9:59 a.m.
On Wednesday 16 April 2014 10:53:59 Mike Crowe wrote:
> On Wednesday 16 April 2014 at 10:49:48 +0100, Paul Eggleton wrote:
> > On Wednesday 16 April 2014 10:31:36 Mike Crowe wrote:
> > > TARGET_LDFLAGS is currently defined in bitbake.conf to contain
> > > ${TARGET_LINK_HASH_STYLE} which differs between MIPS and other
> > > targets. Since TARGET_LDFLAGS is an exported variable it affects the
> > > hash
> > > of every shell task even if it is not used.
> > > 
> > > We don't want native recipe tasks to have different hashes purely
> > > because
> > > they happen to have been built in order to satisfy dependencies for
> > > different MACHINEs since this causes lots of churn in the native sysroot
> > > when switching between MACHINEs.
> > > 
> > > Making native.bbclass override TARGET_LDFLAGS to use BUILD_LDFLAGS
> > > ensures
> > > consistent hashes and is a sensible thing to be doing anyway.
> > 
> > Just to be clear, for a native recipe how is TARGET_LDFLAGS entering the
> > signatures? AIUI there ought to be indirection such that LDFLAGS is used
> > and that is set from BUILD_LDFLAGS for a native recipe rather than
> > TARGET_LDFLAGS.
> 
> Because TARGET_LDFLAGS is an exported variable. LDFLAGS is set from
> TARGET_LDFLAGS but (prior to this patch) only LDFLAGS is set to
> BUILD_LDFLAGS; TARGET_LDFLAGS remains unchanged.
> 
> See thread "export TARGET_LDFLAGS and native sstate"
> <20140407155333.GA19351@mcrowe.com> .
> 
> Should I improve the commit message?

Sorry, I had missed the other thread. If it's exported then we probably do 
need it to have the correct value.

Since this doesn't look like something recent though I'd like to understand 
why it being effectively wrong hasn't been an issue up to this point.

Cheers,
Paul
Mike Crowe - April 16, 2014, 10:07 a.m.
On Wednesday 16 April 2014 at 10:59:27 +0100, Paul Eggleton wrote:
> On Wednesday 16 April 2014 10:53:59 Mike Crowe wrote:
> > On Wednesday 16 April 2014 at 10:49:48 +0100, Paul Eggleton wrote:
> > > On Wednesday 16 April 2014 10:31:36 Mike Crowe wrote:
> > > > TARGET_LDFLAGS is currently defined in bitbake.conf to contain
> > > > ${TARGET_LINK_HASH_STYLE} which differs between MIPS and other
> > > > targets. Since TARGET_LDFLAGS is an exported variable it affects the
> > > > hash
> > > > of every shell task even if it is not used.
> > > > 
> > > > We don't want native recipe tasks to have different hashes purely
> > > > because
> > > > they happen to have been built in order to satisfy dependencies for
> > > > different MACHINEs since this causes lots of churn in the native sysroot
> > > > when switching between MACHINEs.
> > > > 
> > > > Making native.bbclass override TARGET_LDFLAGS to use BUILD_LDFLAGS
> > > > ensures
> > > > consistent hashes and is a sensible thing to be doing anyway.
> > > 
> > > Just to be clear, for a native recipe how is TARGET_LDFLAGS entering the
> > > signatures? AIUI there ought to be indirection such that LDFLAGS is used
> > > and that is set from BUILD_LDFLAGS for a native recipe rather than
> > > TARGET_LDFLAGS.
> > 
> > Because TARGET_LDFLAGS is an exported variable. LDFLAGS is set from
> > TARGET_LDFLAGS but (prior to this patch) only LDFLAGS is set to
> > BUILD_LDFLAGS; TARGET_LDFLAGS remains unchanged.
> > 
> > See thread "export TARGET_LDFLAGS and native sstate"
> > <20140407155333.GA19351@mcrowe.com> .
> > 
> > Should I improve the commit message?
> 
> Sorry, I had missed the other thread. If it's exported then we probably do 
> need it to have the correct value.
> 
> Since this doesn't look like something recent though I'd like to understand 
> why it being effectively wrong hasn't been an issue up to this point.

Perhaps few people are building in the same source tree for both MIPS and
non-MIPS. I don't think you'd notice otherwise.

Even then we only noticed because it seems to be a good way provoke races
in building whilst unpopulating the sysroot (e.g. my recent fix for
cmake-native vs libacl.)

Thanks.

Mike.
Khem Raj - April 16, 2014, 11 p.m.
On Wed, Apr 16, 2014 at 2:59 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Since this doesn't look like something recent though I'd like to understand
> why it being effectively wrong hasn't been an issue up to this point.

because unless you build something like mips and arm in single
workspace you don't have different TARGET_LDFLAGS
and issue remains latent. With mips we change the hash-style since
mips can't support gnu style we have to use sysv and
that changes the TARGET_LDFLAGS but it should not change the
native/nativesdk flags only target flags

Patch

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 5a318d2..2d182f0 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -26,6 +26,10 @@  TARGET_PREFIX = "${BUILD_PREFIX}"
 TARGET_CC_ARCH = "${BUILD_CC_ARCH}"
 TARGET_LD_ARCH = "${BUILD_LD_ARCH}"
 TARGET_AS_ARCH = "${BUILD_AS_ARCH}"
+TARGET_CPPFLAGS = "${BUILD_CPPFLAGS}"
+TARGET_CFLAGS = "${BUILD_CFLAGS}"
+TARGET_CXXFLAGS = "${BUILD_CXXFLAGS}"
+TARGET_LDFLAGS = "${BUILD_LDFLAGS}"
 TARGET_FPU = ""
 
 HOST_ARCH = "${BUILD_ARCH}"