On Thu, Apr 10, 2014 at 9:15 AM, Mike Crowe <m...@mcrowe.com> wrote: > On Monday 07 April 2014 at 17:49:51 +0100, Mike Crowe wrote: > > On Monday 07 April 2014 at 09:17:38 -0700, Chris Larson wrote: > > > On Mon, Apr 7, 2014 at 8:53 AM, Mike Crowe <m...@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" > > > > > > > > > > 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. > > > 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. > > 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. :(
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. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
