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
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Robin Johnson
URL:
Whiteboard:
Keywords:
Depends on: 723264
Blocks: tc-directly perl-toolchain
  Show dependency tree
 
Reported: 2020-05-15 07:07 UTC by Agostino Sarubbo
Modified: 2020-07-05 21:10 UTC (History)
2 users (show)

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


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

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.

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

build log and emerge --info
Comment 2 Kent Fredric (IRC: kent\n) 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) gentoo-dev 2020-05-15 17:02:37 UTC
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.
Comment 4 Kent Fredric (IRC: kent\n) 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):

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(+)
Comment 6 Kent Fredric (IRC: kent\n) 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.