Next to last line.
>>> Emerging (1 of 1) dev-perl/List-MoreUtils-XS-0.426.0::gentoo
* List-MoreUtils-XS-0.426.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking List-MoreUtils-XS-0.426.tar.gz to /var/tmp/portage/dev-perl/List-MoreUtils-XS-0.426.0/work
>>> Source unpacked in /var/tmp/portage/dev-perl/List-MoreUtils-XS-0.426.0/work
>>> Preparing source in /var/tmp/portage/dev-perl/List-MoreUtils-XS-0.426.0/work/List-MoreUtils-XS-0.426 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-perl/List-MoreUtils-XS-0.426.0/work/List-MoreUtils-XS-0.426 ...
* Using ExtUtils::MakeMaker
* perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none DESTDIR=/var/tmp/portage/dev-perl/List-MoreUtils-XS-0.426.0/image/
Checking whether pureperl is required... no
Checking for cc... ld: -pipe: unknown option
ld: use the --help option for usage information
If I change the linker to ld.bfd the next to last line is:
Checking for cc... ld: unrecognised emulation mode: arch=native
CFLAGS="-march=native -O2 -pipe"
Happens on two nearly identical laptops and nearly same configuration gentoo wise.
Will supply more info on command.
The cause of this is likely setting the variable LD= in your environment.
Due to a bunch of complicated things, upstream expects LD to be a CCLD, aka: a CC which can link, like GCC.
Its nuts, but upstream are hard to reason with, and their tools are a gordian knot which makes this hard to workaround.
Its a real bug, but atm, I'm not sure how to deal with it in ways that don't involve hired goons.
Also, please note that the autoconf behaviour mentioned in the linked ticket is not necessarily actual autoconf, but somebody elses re-imagining/interpretation of what autoconf is, which may or may not be the same thing.