Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 723154 - dev-perl/Cache-Memcached-Fast calls ar directly
Summary: dev-perl/Cache-Memcached-Fast calls ar directly
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Robin Johnson
Depends on: 723264
Blocks: tc-directly perl-toolchain
  Show dependency tree
Reported: 2020-05-15 07:07 UTC by Agostino Sarubbo
Modified: 2021-11-04 21:23 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

build.log (build.log,11.08 KB, text/plain)
2020-05-15 07:07 UTC, Agostino Sarubbo

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2020-05-15 07:07:07 UTC
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.

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.
Comment 1 Agostino Sarubbo gentoo-dev 2020-05-15 07:07:15 UTC
Created attachment 639140 [details]

build log and emerge --info
Comment 2 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2020-05-15 14:14:26 UTC
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)
Comment 3 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2020-05-15 17:02:37 UTC
Here is an excerpt from the Makefile that EUMM generates:

> grep '^AR' Makefile
> AR = ar

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.
Comment 4 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2020-05-15 17:07:09 UTC
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 ...
Comment 5 Larry the Git Cow gentoo-dev 2020-05-18 05:44:33 UTC
The bug has been referenced in the following commit(s):

commit 4f1ee98f32a91ea3f84d1c5289d278f8012a8c6a
Author:     Kent Fredric <>
AuthorDate: 2020-05-18 05:41:46 +0000
Commit:     Kent Fredric <>
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, 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, 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:
    --- 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}" \
    Package-Manager: Portage-2.3.99, Repoman-2.3.22
    Signed-off-by: Kent Fredric <>

 dev-lang/perl/perl-5.30.2-r1.ebuild | 654 ++++++++++++++++++++++++++++++++++++
 1 file changed, 654 insertions(+)
Comment 6 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2020-07-05 21:10:16 UTC
This seems to be fixed now with the fixes in dev-lang/perl-5.30.3-r1

Please test.