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

[Elvis Dowson]

Hi,

On Aug 10, 2012, at 8:41 PM, Chris Larson wrote:

> 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.

Copy pasting the tcmode-external-sourcery.inc file from your meta-sourcery repo, to oe-core fixes the issue.

Thanks for the timely assist!!  :-)

Best regards,

Elvis Dowson