[OE-core] Perl5 build issues (meta-cpan only?)

[richard.purdie at linuxfoundation.org]

On Thu, 2019-07-25 at 14:52 +0200, Jens Rehsack wrote:
> Maybe one or the other has already seen the following message in
> connection with modules::Build-based Perl modules:
> ERROR: hash-fieldhash-perl-0.15-r0 do_package_qa: QA Issue: No
> GNU_HASH in the ELF binary /home/sno/gpw-community-bsp/gpw-yocto-
> platform/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/hash-fieldhash-
> perl/0.15-r0/packages-split/hash-fieldhash-
> perl/usr/lib/perl5/vendor_perl/5.30.0/arm-
> linux/auto/Hash/FieldHash/FieldHash.so, didn't pass LDFLAGS?
> [ldflags]
> ERROR: hash-fieldhash-perl-0.15-r0 do_package_qa: QA run found fatal
> errors. Please consider fixing them.
> ERROR: hash-fieldhash-perl-0.15-r0 do_package_qa:
> ERROR: hash-fieldhash-perl-0.15-r0 do_package_qa: Function failed:
> do_package_qa
> ERROR: Logfile of failure stored in: /home/sno/gpw-community-bsp/gpw-
> yocto-platform/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/hash-
> fieldhash-perl/0.15-r0/temp/log.do_package_qa.12168
> ERROR: Task (/home/sno/gpw-community-bsp/sources/meta-cpan/recipes-
> devel/hash-fieldhash-perl/hash-fieldhash-perl_0.15.bb:do_package_qa)
> failed with exit code '1'
> 
> I think the reason is in 
> https://metacpan.org/source/AMBS/ExtUtils-CBuilder-0.280231/lib/ExtUtils/CBuilder/Base.pm#L319
> where the arguments from ldflags are thrown away.

That seems very likely, yes.

> When those issues came up somewhere else than in meta-cpan, please
> let me know (only open-source ^^). We should develop a fix like 
> https://github.com/meta-cpan/meta-cpan/commit/52ded0759daa3bff909bf5fac6d31c6bc52d713e
> then ...
> 
> For now - I think Alberto should receive a patch to use ldflags, too.
> 
> I cannot decide how critic and important that is to make it into
> perl-5.30.1 ...
> When ExtUtils::CBuilder is properly fixed, no changed are required to
> cpan_build.bbclass, aren't they?

I'm not sure I understand exactly what you're asking. I think that if
the question is whether we should fix this in the perl recipe itself
with a patch, so we don't have to add workarounds all over the
metadata, I think the answer is yes, we should.

It would obviously be ideal if such a change were a backported on which
was accepted upstream so we don't have to carry the patch forever! :)

Cheers,

Richard