ActivePerl 5.24.1 32bit ExtUtils::CBuilder link fails on trivial XS; returns non-existent file

Posted by plicease2 on 2017-08-14 07:37

Key problem this code:

my $lib = $cb->link(
objects => [$obj],
module_name => 'Foo',
extra_linker_flags => [],
);

Returns Foo.dll, but not Foo.dll is generated. Key diagnostic appears to be:

n:/lang/perl/active~1/x86/v524~1.1/site/lib/auto/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible N:\lang\perl\activestate\x86\v5.24.1\lib\CORE/libperl524.a when searching for -lperl524

Expected behavior:

Returns Foo.dll with a Foo.dll that can then be used with XSLoader. If it does fail (which it shouldn't for such a trivial example), then it should die instead of returning a bogus file.

Full script and log:

https://gist.github.com/plicease/4e64a414fb175a9358ee3dc50a0f8ba3
https://gist.github.com/plicease/a0ea12e6e981d44e19e3313058d837d8

This script works pretty much everywhere I have tried it except for AS Perl 32bit. It works on Strawberry 32/64bit and AS Perl 64bit.

grahams
ActiveState Staff
Tue, 2017-08-15 11:33

It's using a 64-bit Compiler toolchain, which isn't compatible with the 32-bit libperl524.a file.

I'm not sure how that 64-bit ld.exe got into your site/lib, but it could be a known issue with PPM. When you have two versions of ActivePerl, the only PPM that will work correctly is the last one installed. If you installed 64-bit last, your 32-bit version can't use PPM to manage modules until you uninstall the 64-bit version.

Strawberry would be tightly linked to it's 32bit compiler toolchain, so that can't happen.