This is an auto-filled bug because dev-perl/Cache-Memcached-Fast calls ar directly. The issue was originally discovered on amd64, but it may be reproducible on other arches as well. If you think that a different summary clarifies the issue better, feel free to change it. Attached build log and emerge --info. NOTE: If you think it doesn't make sense fix these type of issues, I'd like to point out that won't be possible use a different AR implementation (like llvm-ar) by setting the AR variable. So this issue has been reproduced by setting the AR variable to x86_64-pc-linux-gnu-ar and by removing the /usr/bin/ar binary.
Created attachment 639140 [details] build.log build log and emerge --info
I don't see any mention of "cc" or "ar" explicitly in the source code for this, so its almost surely ExtUtils::MakeMaker's doing (which may mean perl was compiled wrong, or differently from the config used for this build)
Here is an excerpt from the Makefile that EUMM generates: > grep '^AR' Makefile > > AR = ar > AR_STATIC_ARGS = cr > ARMAYBE = : Which of course is stupid, but yeah, thanks EUMM, so everything either EUMM or MB ( so that's everything with XS at all ), will be broken.
The only good news is it seems hackable: > # AR="x86_64-pc-linux-gnu-ar" make > ar cr libclient.a parse_keyword.o compute_crc32.o array.o client.o connect.o dispatch_key.o socket_posix.o make[1]: ar: No such file or directory > # make AR="x86_64-pc-linux-gnu-ar" > x86_64-pc-linux-gnu-ar cr libclient.a parse_keyword.o compute_crc32.o array.o client.o connect.o dispatch_key.o socket_posix.o > /usr/bin/ranlib libclient.a ... continues So a simile addition in affected packages of AR="${AR}" to the "make" invocation might be sufficient. A quick grep indicates we do this for a few packages already, but differently: > ./Net-DNS/Net-DNS-1.100.0.ebuild: emake FULL_AR="$(tc-getAR)" OTHERLDFLAGS="${LDFLAGS}" > ./Net-DNS/Net-DNS-1.130.0.ebuild: emake FULL_AR="$(tc-getAR)" OTHERLDFLAGS="${LDFLAGS}" > ./Net-Patricia/Net-Patricia-1.220.0-r1.ebuild: emake AR="$(tc-getAR)" OTHERLDFLAGS="${LDFLAGS}" > ./Math-Pari/Math-Pari-2.10.809.0-r1.ebuild: emake AR="$(tc-getAR)" OTHERLDFLAGS="${LDFLAGS}" Have to work out why some use FULL_AR= and others use AR= now ...
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(+)
This seems to be fixed now with the fixes in dev-lang/perl-5.30.3-r1 Please test.
