I am using ActiveState Perl 5.8.8 (817) and trying to build [cpan://Devel::Caller] with [http://www.mingw.org/|MinGW]. The odd thing is that it is failing to find -lperl58
Here is the output of perl Makefile.PL
C:\Devel-Caller-0.11>perl Makefile.PL # running Build.PL Set up gcc environment - 3.4.2 (mingw-special) Set up gcc environment - 3.4.2 (mingw-special) Set up gcc environment - 3.4.2 (mingw-special) C:\Perl\bin\perl.exe Build.PL Set up gcc environment - 3.4.2 (mingw-special) Set up gcc environment - 3.4.2 (mingw-special) Checking whether your kit is complete... Looks good Checking prerequisites... Looks good Creating new 'Build' script for 'Devel-Caller' version '0.11' Set up gcc environment - 3.4.2 (mingw-special)
Here is the output of mingw32-make
C:\Devel-Caller-0.11>mingw32-make
C:\Perl\bin\perl.exe Build --makefile_env_macros 1
Set up gcc environment - 3.4.2 (mingw-special)
Set up gcc environment - 3.4.2 (mingw-special)
Set up gcc environment - 3.4.2 (mingw-special)
Set up gcc environment - 3.4.2 (mingw-special)
lib\Devel\Caller.pm -> blib\lib\Devel\Caller.pm
lib\Devel\Caller.xs -> lib\Devel\Caller.c
C:\Perl\bin\perl.exe -IC:\Perl\lib -IC:\Perl\lib C:\Perl\lib\ExtUtils\xsubpp -noprototypes -typemap C:\Perl\lib\ExtUtils\typemap lib\Devel\Caller.xs
gcc -c -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -DHASATTRIBUTE -fno-strict-aliasing -O2 "-DXS_VERSION=\"0.11\"" "-DVERSION=\"0.11\"" -I"C:\Perl\lib\CORE" -I"\include" -o "lib\Devel\Caller.o" "lib\Devel\Caller.c"
ExtUtils::Mkbootstrap::Mkbootstrap('blib\arch\auto\Devel\Caller\Caller.bs')
Generating script 'lib\Devel\Caller.lds'
dlltool --def "lib\Devel\Caller.def" --output-exp "lib\Devel\Caller.exp"
gcc -o "blib\arch\auto\Devel\Caller\Caller.dll" -Wl,--base-file,"lib\Devel\Caller.base" -Wl,--image-base,0x26130000 -mdll "lib\Devel\Caller.lds" "lib\Devel\Caller.exp"
C:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -lperl58
collect2: ld returned 1 exit status
dlltool --def "lib\Devel\Caller.def" --output-exp "lib\Devel\Caller.exp" --base-file "lib\Devel\Caller.base"
gcc -o "blib\arch\auto\Devel\Caller\Caller.dll" -Wl,--image-base,0x26130000 -mdll "lib\Devel\Caller.lds" "lib\Devel\Caller.exp"
C:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -lperl58
collect2: ld returned 1 exit status
Manifying blib\lib/Devel/Caller.pm -> blib\libdoc\Devel.Caller.3
HTMLifying blib\lib\Devel\Caller.pm -> blib\libhtml\site\lib\Devel\Caller.html
Build: blib\lib\Devel\Caller.pm: unterminated list at =head in paragraph 30. ignoring.
Build: blib\lib\Devel\Caller.pm: cannot resolve L in paragraph 31.
Build: blib\lib\Devel\Caller.pm: cannot resolve L in paragraph 50.
Build: blib\lib\Devel\Caller.pm: cannot resolve L in paragraph 50.
While I would be just as happy if someone could point me to a ppm repository with a current [cpan://Devel::Caller], I would truly like to figure out why a default lib can't be found.
Any and all help is appreciated.
Cheers - [Limbic~Region|L~R]
Best I could come up with was to use this Makefile.PL:
use ExtUtils::MakeMaker;
WriteMakefile(
'NAME' => 'Devel::Caller',
'VERSION_FROM' => 'lib/Devel/Caller.pm', # finds $VERSION
);
Also you need to copy lib/Devel/Caller.xs up 2 levels (to the root directory of the source distro). Then run 'dmake clean' (or 'mingw32-make clean') to get back to a fresh installation. Then run 'perl Makefile.PL', 'dmake test', 'dmake install'. Some of the tests fail - same happens on my MinGW-built perl. And the output of 'dmake test' is a little nonsensical (and 'nmake test', too ... which is why the CPAN testers reckon it builds on Win32 ... though it doesn't). For a better understanding of which tests failed and which tests passed, run 'perl -Mblib t\Devel-Caller.t' I see ActiveState have a ppm for Devel-Caller-Perl. Perhaps that's worth checking out.
Cheers,
Rob
I think there's an element of Module::Build bugginess involved here
bart and I are coming to the same conclusion. Oddly enough, the last ppd I can find for Devel::Build is .08 and according to the changes file, it ported to Module::Build at .09 version. Oddly enough, the test report shows the current version building on Win32 when MVC++ is used as the compiler. This leads me to believe it is a ActiveState/MinGW/Module::Build problem. I have several different makes lying around so that isn't the problem as I see the behavior with all of them.
Interestingly enough, my
Thanks so much for figuring out a work around!!!! Any suggestions on who to contact on a real fix would be appreciated.
Cheers - L~R
The problem is so bad that I can't even install Module::Build 0.2805, because the tests fail for the exact same reason.
The solution that works for me, is find a way to specify that directory into the command line for the linker. Open the file C:\Perl\site\lib\ActivePerl\Config.pm, and replace the line 108,
_override("lddlflags", "-mdll");
which is one of the parameters passed to the linker, with
_override("lddlflags", "-mdll -LC:/Perl/lib/CORE");
Now, Module::Build passes all tests. And, after installing [module://Module::Build], so does [cpan://Devel::Caller].
Very interesting though this workaround is just that - a workaround. I would be interested in knowing who the right people are to get a real fix for this. The alternative I found for Devel::Caller was just to bypass Module::Build though I have confirmed your workaround also works.
Cheers - L~R
lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl\lib\CORE" -machine:x86'
And here is what is made of in in ActivePerl::Config:
_override("lddlflags", "-mdll");
which lists the option for the dynamic libraries, i.e. the DLLs made out of the XS modules.
Do you see anything missing? Well, actually, a lot is missing, but most importantly, the command line switch to include the library search directory "C:\Perl\lib\CORE" is not there any more.
So, with a bit of cleanup, i.e. poring the library path out of _orig_config instead of hardcoding it, I guess I have the most acceptable patch.
update I've made a more politically correct patch, which gets the (MSVC style) -libpath: parameter switches out of the original lddlflags setting, and replaces each with the gcc style -L switch for MinGW. I've tested it and it seems to work, even with quotes and backslashes in place.
_override("lddlflags", join " ", "-mdll",
map "-L$_", map /^-libpath:(.+)/,
_orig_conf("lddlflags") =~ /(?=\S)(?>[^"\s]+|"[^"]*")+/g);
update The code has been updated (from a simple split " ") so it can properly handle spaces embedded between quotes.
It does not suprise me that there is a problem with ActiveState's customization as it isn't the first time I have encountered such a problem. The thing that has me puzzled is why this only appears to affect ActiveState with MinGW with Module::Build. Trying other configurations have worked just fine for me.
Update: I suppose it is because ExtUtils::MakeMaker specifies an absolute path to perl58.lib and MSVC++ doesn't use the customize configuration.
Cheers - L~R
I think bart is correct in pointing the finger of accusation at 'lddlflags'. On my MinGW-built perl:
D:\>perl -V:lddlflags
lddlflags='-mdll -s -L"D:\perl58_M\5.8.8\lib\CORE" -L"D:\MinGW\lib"';
On ActiveState build 817:
E:\>perl -V:lddlflags
Set up gcc environment - 3.4.4 (mingw special)
lddlflags='-mdll';
Presumably this affects only M::B because M::B is the only module that needs to have the lddlflags specify the path to perl58.lib ... at least it's the only module you've come across where this has been the case. ActiveState should fix the lddlflags value to include the perl/lib/CORE searchpath when MinGW is involved.
I don't think the MinGW/ActivePerl interface is quite as seamless as the hype would have you believe. Last time I tried, neither PAR nor Inline::CPP would build. If you want to use MinGW with ActivePerl, I think you'll get more milage with ExtUtils::FakeConfig - which does set lddlflags (and others) appropriately, though I think there were a couple of entries in Config_m.pm (created by EU::FC) that needed amendment - I can provide details of that if requested. The drawback to EU::FC is that sometimes (eg building Inline::CPP or building PDL) you need to set the environment variable perl5opt to MConfig_m. Other times you may need that variable unset.
According to http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/Devel-Caller-0.11.txt the ppm for Devel-Caller-0.11 did not build because the pre-requisite Module::Build is not installed.
Oh ... and I now gather that failing tests marked as 'TODO' are allowed to fail ... didn't realise that when I first posted :-)
Cheers,
Rob
Well, the ActiveState and MinGW integration is a work in progress. I emailed Jan Dubois yesterday after [bart] and [Intrepid] tracked down the bug and a patch to ActivePerl has already been made and will be reflected in build 818. Here is the patch Jan applied:
@@ -112,12 +112,16 @@
_override("_o", ".o");
_override("obj_ext", ".o");
_override("optimize", "-O2");
- _override("lddlflags", "-mdll");
_override("i64type", "long long");
_override("u64type", "unsigned long long");
_override("quadtype", "long long");
_override("uquadtype", "unsigned long long");
_override("d_casti32", "define");
+
+ # Extract all library paths from lddlflags
+ my @libpaths = map "-L$_", map /^-libpath:(.+)/,
+ _orig_conf("lddlflags") =~ /(?=\S)(?>[^"\s]+|"[^"]*")+/g;
+ _override("lddlflags", join(" ", "-mdll", @libpaths));
}
}
elsif ($^O eq 'darwin') {
So with responsiveness like that, I have hopes for ActivePerl and MinGW. I am frustrated by the fact that I can't remember what other customization I have had problems with in the past and just fixed my local copy - I should have emailed that too.
Cheers - [Limbic~Region|L~R]