[yocto] external-sourcery-toolchain: ERROR: QA Issue: No GNU_HASH in the elf binary

[Chris Larson]

On Fri, Aug 10, 2012 at 9:37 AM, Elvis Dowson <elvis.dowson at gmail.com> wrote:
>       I'm building with the mentor external-sourcery-toolchain.
>
> I get the following error:
>
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipcloak'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zip'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipsplit'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipnote'
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/temp/log.do_package.47453
>
> Adding the following statement to zip.bb doesn't fix the problem, like it
> used to when using the gcc-4.x compilers:
>
> TARGET_CC_ARCH += "${LDFLAGS}"

I have bits that work around this by making the ldflags/gnu_hash check
nonfatal when using this toolchain, but they haven't gone into oe-core
yet. See https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc#L87-94
for details. You should be able to try a build using this layer, or
just grab those bits and put them into your oe-core
tcmode-external-sourcery.inc.

I haven't had time to pursue this meta-sourcery wrt upstream yet, but
I think in the long term it's the best approach for supporting the
sourcery g++ toolchain. I think all we should keep in oe-core is
either a sample/example config, a link to that layer, or a
configuration for a toolchain that doesn't require as much tweaking
(e.g. tuning arguments), such as crosstool-ng. That isn't related to
your issue, but is why I haven't been quite as proactive about pushing
fixes to the tcmode in oe-core recently.
-- 
Christopher Larson