So, I built my perl like ago. No /usr/bin/ar AR=x86_64-pc-linux-gnu-ar in make.conf 1. It fails its own test suite. 2. If installed without testing, then: > /usr/bin/perl -V:ar > ar='ar'; Which is garbage, because that means anyone using even *CPAN's* encouraged pattern of "Ask Config what perl used, and use that", are getting flat out lied to. Config is recording that it was built against an AR called "ar", which it most certainly wasn't! And most(all) the ways of building perl stuff *DONT* respect AR from ENV, they override it in Makefile, and ExtUtils::MakeMaker decides what goes in there! And its .... "ar", which is wrong. You can only workaround that by explicitly doing: emake AR="$AR" or similar. So, this is a fire to light under an ass, because perl C stuff is basically screwed without this working.
Also good news: Patching Config_heavy.pl to have the right value for "ar" fixes both bug #723154 and bug #723222 ! :)
(In reply to Kent Fredric (IRC: kent\n) from comment #1) > Also good news: Patching Config_heavy.pl to have the right value for "ar" > fixes both bug #723154 and bug #723222 ! :) Scratch the Data-Dump-Streamer being fixed, I didn't make sure to repro it first. DDS is fine with stock perl AR settings, and is being messed up by LD being an actual LD, when it expects a CCLD, and is passing CFLAGS to it..... which LD does not support.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f1ee98f32a91ea3f84d1c5289d278f8012a8c6a commit 4f1ee98f32a91ea3f84d1c5289d278f8012a8c6a Author: Kent Fredric <kentnl@gentoo.org> AuthorDate: 2020-05-18 05:41:46 +0000 Commit: Kent Fredric <kentnl@gentoo.org> CommitDate: 2020-05-18 05:44:06 +0000 dev-lang/perl: Enforce toolchain `ar` in ./configure This one neat trick convinces ./configure to use a correct, and specified "ar" during configure, as auto-detection completely fails when there is no binary named "ar" in $PATH, and despite completely failing to detect any "ar", configure just warns, and continues as normal, and then hardcodes that total failure of detection in Config_heavy.pl, indicating "hey, the 'ar' perl was built with was 'ar'", despite no such thing existing, and code afterwards will then try ( and fail ) to use that `ar` by consulting $Config{ar} This step compeletely side-steps auto-detection, so at very least, Config_heavy.pl contains a value that at least one time, probably worked, and as a result, large amounts of EUMM/MB XS stuff no longer tries to use a default `ar` that never existed. -r1 bump required, as the consequences of this change propagate into everything that compiles C code against Perl, and a failure to upgrade perl with this fix results in future failures compiling other stuff But otherwise this really is just a one line fix: ```diff --- perl-5.30.2.ebuild 2020-04-13 01:31:59.268561073 +1200 +++ perl-5.30.2-r1.ebuild 2020-05-18 16:46:13.972962817 +1200 @@ -507,4 +507,5 @@ -Darchname="${myarch}" \ -Dcc="$(tc-getCC)" \ + -Dar="$(tc-getAR)" \ -Doptimize="${CFLAGS}" \ -Dldflags="${LDFLAGS}" \ ``` Bug: https://bugs.gentoo.org/723264 Bug: https://bugs.gentoo.org/723154 Bug: https://github.com/Perl/perl5/issues/17791 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Kent Fredric <kentnl@gentoo.org> dev-lang/perl/perl-5.30.2-r1.ebuild | 654 ++++++++++++++++++++++++++++++++++++ 1 file changed, 654 insertions(+)
Ok well it's fixed then.
