Bug #120907 for List-MoreUtils: ::XS : 'ld' used as if it was 'cc' when LD is set in ENV

On 2017-04-04 04:22:00, REHSACK wrote:
> Qualified user expected - see
> http://www.gnu.org/software/autoconf/manual/autoconf.html.

Can you expand a little more? Perhaps point to a relevant section?

CC being pointed at a valid compiler, and LD being pointed at a valid linker , Its not clear to me how this is an error the user has made.

It seems to me the problem is that something in your Perl stack tries to call LD with compile flags, but I don't know where to start looking.

LD should _not_ be called with compile flags.

-- 
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )
 

On 2017-04-04 04:57:28, REHSACK wrote:

> Then be a good user and DON'T CALL IT WITH COMPILE FLAGS.

But that's entirely the point: I'm not calling it with compile flags.

This is, verbatim, what I can do to replicate the failure.

 cpanm --look List::MoreUtils::XS
--> Working on List::MoreUtils::XS
Fetching http://www.cpan.org/authors/id/R/RE/REHSACK/List-MoreUtils-XS-0.418.tar.gz ... OK
Entering /home/kent/.cpanm/work/1491238831.381/List-MoreUtils-XS-0.418 with /bin/bash
kent@katipo2 ~/.cpanm/work/1491238831.381/List-MoreUtils-XS-0.418 $ LD=ld CC=cc perl Makefile.PL
Checking whether pureperl is required... no
Checking for cc... ld: unrecognised emulation mode: tune=native

^ and then it dies.

Is there any other information that I can give that would make it clearer why this is happening?

Because "The User" here hasn't passed any CFLAGS that I'm aware of.

If anyone has passed any wrong CFLAGS, it was likely me (somehow) in some part of normal perl build.

But there's no CFLAGS being passed to LMU-XS here that I can see.

-- 
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )
 

On 2017-04-04 05:12:42, REHSACK wrote:

> This is always an error, since a perl module must build must rely on
> perl build flags to create same ABI. Specifying LD without LDFLAGS
> causes $ENV{LD} runs with $Config{ldflags} - that's never a good idea,
> isn't it? Except for very particular cases.

In this case, the user was specifying an explict LD when they compiled perl, in order to prevent Perl from compiling with the default, GNU's LD, because the user wants an LLVM stack.

Which means they have the same value of LD in their environment that they used to build perl, when they build List::MoreUtils::XS

I asked them to remove LD from their environment, and this leads LMU to pick a different LD

/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld

Which for them, is the wrong LD , and gives them similar problems. (Sorry if I'm vague, trying to extract data out of 3rd parties through 3rd paries is difficult )

It seems to me that given the behaviour, and given how setting LD in ENV does the right thing for the rest of the operating system ( and indeed, normal autoconf handles it correctly on a regular basis ), that it might not be entirely wrong for their use case.

So here, the combination of custom LD and $Config{ldflags}  is right, *because* its the same conditions Perl Itself builds under.

Its only leaving LD UNset that introduces the "wrong condition", if I understand correctly.

However, the user I was helping has decided to resort to unsetting LD in environment, and then maintaining /usr/bin/ld as a symlink to the desired LD instead, as that seems to work better for LMU-XS ( after recompiling perl with it this way of course )

The only reason they didn't do that in the first place is every binutils update replaces that symlink and brings them back to using the GNU stack instead of the LLVM stack, which is wrong for them.


-- 
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )