<p dir="ltr"></p>
<p dir="ltr">-Khem<br>
On Apr 7, 2014 5:53 AM, "Mike Crowe" <<a href="mailto:mac@mcrowe.com">mac@mcrowe.com</a>> wrote:<br>
><br>
> We're building for both ARM and MIPS-based MACHINEs in a single source<br>
> tree. This seems to result in us compiling (or luckily most of the time<br>
> resurrecting from sstate-cache) two different versions of all -native<br>
> packages due to different base hashes.<br>
><br>
> It seems that this difference in base hashes is due to the exported<br>
> variable TARGET_LDFLAGS being different between the two CPUs:<br>
><br>
> < export TARGET_LDFLAGS="-Wl,-O1 -Wl,--as-needed"<br>
> ---<br>
> > export TARGET_LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"<br>
><br>
> which in turn is because TARGET_LINK_HASH_STYLE is explicitly set to "sysv"<br>
> on MIPS but allowed to be "gnu" on everything else.<br>
><br>
> Every time I switch back and forth between building ARM-based and<br>
> MIPS-based machines the do_populate_sysroot_setscene tasks run for each<br>
> required -native recipe.<br>
><br>
> If I modify native.bbclass to do:<br>
><br>
> TARGET_LDFLAGS = "${BUILD_LDFLAGS}"</p>
<p dir="ltr">this is reasonable to do<br>
><br>
> then the hashes match and this unnecessary sysroot population is avoided.<br>
><br>
> Is this a sensible thing to be doing? It does mean that TARGET_LDFLAGS<br>
> contains a lot of (presumably unnecessary) rpath shenanigans but perhaps<br>
> that doesn't matter. :(<br>
><br>
> Thanks.<br>
><br>
> Mike.<br>
> --<br>
> _______________________________________________<br>
> Openembedded-core mailing list<br>
> <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.openembedded.org</a><br>
> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</p>