export TARGET_LDFLAGS and native sstate
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"
---
Quoted 1 line
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}"
then the hashes match and this unnecessary sysroot population is avoided.
Is this a sensible thing to be doing? It does mean that TARGET_LDFLAGS contains a lot of (presumably unnecessary) rpath shenanigans but perhaps that doesn't matter. :(
Thanks.
Mike.
Quoted 12 lines · Chris Larson
Quoted 10 lines · Mike Crowe
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_LDFLAGSbeing different between the two CPUs:< export TARGET_LDFLAGS="-Wl,-O1 -Wl,--as-needed"
---
Quoted 7 lines
Quoted 2 lines
Quoted 1 line
export TARGET_LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
Heh, this i another case of a likely completely unnecessary export. Software we build expects LDFLAGS to be used, not
TARGET_LDFLAGS, so I can't imagine that anything is using this export. Of course, it's non-trivial to confirm that this is the case :)
It did strike me as an odd thing to be exporting. Given the name I assumed it had something to do with building the toolchain. I notice though that the gcc recipes explicitly export LDFLAGS_FOR_TARGET inside tasks based on TARGET_LDFLAGS anyway so the toolchain "should be fine". :)
I'm happy to try our complete build without exporting TARGET_LDFLAGS as a first step but I realise that probably wouldn't be enough proof.
Thanks.
Mike.
-Khem
Quoted 6 lines · Mike Crowe
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.
Quoted 8 lines
It seems that this difference in base hashes is due to the exported variable
TARGET_LDFLAGSbeing different between the two CPUs:< export TARGET_LDFLAGS="-Wl,-O1 -Wl,--as-needed"
---Quoted 1 line
export TARGET_LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
which in turn is because
TARGET_LINK_HASH_STYLEis explicitly set to
"sysv"
Quoted 9 lines
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_setscenetasks run for each required -native recipe.If I modify native.bbclass to do:
TARGET_LDFLAGS= "${BUILD_LDFLAGS}"
this is reasonable to do
Quoted 15 lines
then the hashes match and this unnecessary sysroot population is avoided.
Is this a sensible thing to be doing? It does mean that
TARGET_LDFLAGScontains a lot of (presumably unnecessary) rpath shenanigans but perhaps that doesn't matter. :(Thanks.
Mike.
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 5 lines · Mike Crowe
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.
Quoted 7 lines
It seems that this difference in base hashes is due to the exported variable
TARGET_LDFLAGSbeing different between the two CPUs:< export TARGET_LDFLAGS="-Wl,-O1 -Wl,--as-needed"
---Quoted 1 line
export TARGET_LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
Heh, this i another case of a likely completely unnecessary export. Software we build expects LDFLAGS to be used, not TARGET_LDFLAGS, so I can't imagine that anything is using this export. Of course, it's non-trivial to confirm that this is the case :)
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 13 lines · Mike Crowe
Quoted 12 lines · Chris Larson
Quoted 10 lines · Mike Crowe
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_LDFLAGSbeing different between the two CPUs:< export TARGET_LDFLAGS="-Wl,-O1 -Wl,--as-needed"
---
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
Quoted 1 line
export TARGET_LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
Heh, this i another case of a likely completely unnecessary export. Software we build expects LDFLAGS to be used, not
TARGET_LDFLAGS, so I can't imagine that anything is using this export. Of course, it's non-trivial to confirm that this is the case :)
My git archaeology shows that this dates from the very first import from svn back in 2005. Back then it looks like it was necessary for wpa_supplicant which used it in its defconfig file. This is no longer the case.
I didn't look at any other layers.
Quoted 7 lines
It did strike me as an odd thing to be exporting. Given the name I assumed it had something to do with building the toolchain. I notice though that the gcc recipes explicitly export
LDFLAGS_FOR_TARGETinside tasks based onTARGET_LDFLAGSanyway so the toolchain "should be fine". :)I'm happy to try our complete build without exporting
TARGET_LDFLAGSas a first step but I realise that probably wouldn't be enough proof.
I've tested our build without the "export" in front of TARGET_LDFLAGS in bitbake.conf and saw no problems at all so I'm in favour of doing that.
Would a patch for this be acceptable? It does cause the world to be rebuilt. :(
Thanks.
Mike.
Quoted 39 lines · Mike Crowe
Quoted 4 lines · Mike Crowe
Quoted 3 lines · Chris Larson
Quoted 1 line · Mike Crowe
We're building for both ARM and MIPS-based MACHINEs in a single
source
Quoted 1 line
Quoted 1 line
Quoted 1 line
tree. This seems to result in us compiling (or luckily most of the
time
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
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_LDFLAGSbeing different between the two CPUs:< export TARGET_LDFLAGS="-Wl,-O1 -Wl,--as-needed"
---Quoted 1 line
export TARGET_LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed"
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Heh, this i another case of a likely completely unnecessary export. Software we build expects LDFLAGS to be used, not
TARGET_LDFLAGS, so I can't imagine that anything is using this export. Of course, it's non-trivial to confirm that this is the case :)My git archaeology shows that this dates from the very first import from svn back in 2005. Back then it looks like it was necessary for
wpa_supplicantwhich used it in its defconfig file. This is no longer the case.I didn't look at any other layers.
Quoted 1 line
It did strike me as an odd thing to be exporting. Given the name I
assumed
Quoted 2 lines
it had something to do with building the toolchain. I notice though that the gcc recipes explicitly export
LDFLAGS_FOR_TARGETinside tasks basedon
Quoted 2 lines
TARGET_LDFLAGSanyway so the toolchain "should be fine". :)
Quoted 8 lines
Quoted 2 lines
I'm happy to try our complete build without exporting
TARGET_LDFLAGSas a first step but I realise that probably wouldn't be enough proof.I've tested our build without the "export" in front of
TARGET_LDFLAGSin bitbake.conf and saw no problems at all so I'm in favour of doing that.Would a patch for this be acceptable? It does cause the world to be rebuilt. :(
I'm a fan of this, personally, but you'll likely need to check with folks like Richard Purdie for a final call, and this particular fix would have to go in post-1.6, into the 1.7 timeframe (1.6 isn't branched yet) since we're in the release candidate phase, and this has inherent risk. So, it might be worth pursuing the merge of the workaround with alters TARGET_LDFLAGS in native.bbclass to improve sstate reuse for 1.6, then pursue the unexport of TARGET_LDFLAGS for 1.7.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 47 lines · Chris Larson
Quoted 45 lines · Mike Crowe
Quoted 4 lines · Mike Crowe
Quoted 3 lines · Chris Larson
Quoted 1 line · Mike Crowe
We're building for both ARM and MIPS-based MACHINEs in a single
source
Quoted 1 line
Quoted 1 line
Quoted 1 line
tree. This seems to result in us compiling (or luckily most of the
time
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
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_LDFLAGSbeing different between the two CPUs:< export TARGET_LDFLAGS="-Wl,-O1 -Wl,--as-needed"
---Quoted 1 line
export TARGET_LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed"
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Heh, this i another case of a likely completely unnecessary export. Software we build expects LDFLAGS to be used, not
TARGET_LDFLAGS, so I can't imagine that anything is using this export. Of course, it's non-trivial to confirm that this is the case :)My git archaeology shows that this dates from the very first import from svn back in 2005. Back then it looks like it was necessary for
wpa_supplicantwhich used it in its defconfig file. This is no longer the case.I didn't look at any other layers.
Quoted 1 line
It did strike me as an odd thing to be exporting. Given the name I
assumed
Quoted 2 lines
it had something to do with building the toolchain. I notice though that the gcc recipes explicitly export
LDFLAGS_FOR_TARGETinside tasks basedon
Quoted 4 lines
TARGET_LDFLAGSanyway so the toolchain "should be fine". :)I'm happy to try our complete build without exporting
TARGET_LDFLAGSas a first step but I realise that probably wouldn't be enough proof.I've tested our build without the "export" in front of
TARGET_LDFLAGSin bitbake.conf and saw no problems at all so I'm in favour of doing that.
Quoted 7 lines
Quoted 2 lines
Would a patch for this be acceptable? It does cause the world to be rebuilt. :(
I'm a fan of this, personally, but you'll likely need to check with folks like Richard Purdie for a final call, and this particular fix would have to go in post-1.6, into the 1.7 timeframe (1.6 isn't branched yet) since we're
^^^ looks like it just got branched off less than an hour ago...
Quoted 16 lines
in the release candidate phase, and this has inherent risk. So, it might be worth pursuing the merge of the workaround with alters
TARGET_LDFLAGSin native.bbclass to improve sstate reuse for 1.6, then pursue the unexport ofTARGET_LDFLAGSfor 1.7.Signature · 11 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 23 lines · Khem Raj
-Khem
Quoted 6 lines · Mike Crowe
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.
Quoted 8 lines
It seems that this difference in base hashes is due to the exported variable
TARGET_LDFLAGSbeing different between the two CPUs:< export TARGET_LDFLAGS="-Wl,-O1 -Wl,--as-needed"
---Quoted 1 line
export TARGET_LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
which in turn is because
TARGET_LINK_HASH_STYLEis explicitly set to"sysv"
Quoted 6 lines
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_setscenetasks run for each required -native recipe.
Quoted 5 lines
Quoted 3 lines
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 <[email protected]> . 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.