Skip Menu |
 

This queue is for tickets about the List-MoreUtils CPAN distribution.

Report information
The Basics
Id: 120907
Status: rejected
Priority: 0/
Queue: List-MoreUtils

People
Owner: Nobody in particular
Requestors: KENTNL [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: ::XS : 'ld' used as if it was 'cc' when LD is set in ENV

Apologies if this is the wrong queue, metacpan bug tracking data points to this one still :)

When LD is set in ENV, something in configure eventually tries to pass CC args to it, which are invalid for LD, and then fails:

A trivial reproduction is:

LD=ld CC=cc perl Makefile.PL
Checking whether pureperl is required... no
Checking for cc... ld: unrecognised emulation mode: tune=native
Supported emulations: <BIG LIST>

Can't produce loadable XS module at Makefile.PL line 44.

This was reported to me by a user who has their stack configured for LLVM, which is much more strict about invalid ldflags:
 

Checking whether pureperl is required... no
Checking for cc... /usr/bin/ld.lld: error: unknown argument: -pipe
/usr/bin/ld.lld: error: unknown argument: -fomit-frame-pointer
/usr/bin/ld.lld: error: unknown argument: -Wl,-O2
/usr/bin/ld.lld: error: unknown argument: -Wl,--as-needed


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

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 Mon Apr 03 12:51:18 2017, KENTNL wrote: Show quoted text
> 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?
For your particular issue, dunno. Show quoted text
> 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.
When setting LD, you always have to set LDFLAGS, too. Or trust the right LD is determined. The particular issue comes up, when configure (in this case, perl's configure which is used as source for flags to use to create same ABI) determines linking should be done via cc (very common these days), and thus linker executable is taken from CCLD and linker flags from CCLDFLAGS. Show quoted text
> 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.
In my? Seriously? Show quoted text
> LD should _not_ be called with compile flags.
Then be a good user and DON'T CALL IT WITH COMPILE FLAGS. Cheers, Jens

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 )
 

Download (untitled) / with headers
text/plain 1.1k
On Mon Apr 03 13:05:58 2017, KENTNL wrote: Show quoted text
> 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.
You do by omitting them. At the very moment Config::AutoConf relies on ExtUtils::CBuilder. I thought about implementing something better which can be used for makefile generation, either (e.g. for improving Perl6 Toolchain - but there is a blocker in Perl6 tooling meanwhile which prevents me from jumping in and just for weird Perl5 Tooling I don't want to invest that much of time) Show quoted text
> This is, verbatim, what I can do to replicate the failure. > > cpanm --look List::MoreUtils::XS
It is very important, either set all or none tunable environment variables - or, of set particular ones, know what the tune. Show quoted text
> kent@katipo2 ~/.cpanm/work/1491238831.381/List-MoreUtils-XS-0.418 $ LD=ld CC=cc perl Makefile.PL
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. Cheers, Jens

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 )
 

Download (untitled) / with headers
text/plain 2.1k
On Mon Apr 03 13:51:18 2017, KENTNL wrote: Show quoted text
> 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.
In that case - which seems to be a very weird setup the user has, it should set LD to ${CCLD} - which is typically just 'cc'.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.