Limbic~Region has asked for the wisdom of the Perl Monks concerning the following question:

All,
I am using ActiveState Perl 5.8.8 (817) and trying to build Devel::Caller with 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-al +iasing -O2 "-DXS_VERSION=\"0.11\"" "-DVERSION=\"0.11\"" -I"C:\Perl\li +b\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.ex +p" gcc -o "blib\arch\auto\Devel\Caller\Caller.dll" -Wl,--base-file,"lib\D +evel\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.ex +p" --base-file "lib\Devel\Caller.base" gcc -o "blib\arch\auto\Devel\Caller\Caller.dll" -Wl,--image-base,0x261 +30000 -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\Cal +ler.html Build: blib\lib\Devel\Caller.pm: unterminated list at =head in paragra +ph 30. ignoring. Build: blib\lib\Devel\Caller.pm: cannot resolve L<perlfunc/caller> in +paragraph 31. Build: blib\lib\Devel\Caller.pm: cannot resolve L<perlfunc/caller> in +paragraph 50. Build: blib\lib\Devel\Caller.pm: cannot resolve L<PadWalker> in paragr +aph 50.

While I would be just as happy if someone could point me to a ppm repository with a current Devel::Caller, I would truly like to figure out why a default lib can't be found.
Any and all help is appreciated.

Cheers - L~R

Replies are listed 'Best First'.
Re: Help building Devel::Caller
by bart (Canon) on Aug 02, 2006 at 16:30 UTC
    It's, as stated, typically a problem you have with Module::Build in ActivePerl with the non-original C compiler — thus: MinGW. What happens is that Module::Build for some obscure reason uses -lperl58 as a libary to link against, which is short for perl58.lib in any searched directory, but the directory C:\Perl\lib\CORE, where perl58.lib actually resides, isn't in the search path.

    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::Build, so does Devel::Caller.
      bart,
      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

        Despite your skeptiscism, after some more digging together with Intrepid who enjoys messing with build problems, I appear to have found the exact spot of the problem. You see, here is the line in Config Config_heavy.pl for ActivePerl5.8.8:
        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.

Re: Help building Devel::Caller
by syphilis (Archbishop) on Aug 02, 2006 at 15:26 UTC
    I think there's an element of Module::Build bugginess involved here ... or perhaps it's the ActiveState/MinGW interaction that's buggy. You may also be better off using 'dmake' instead of 'mingw32-make' (http://search.cpan.org/dist/dmake/) though that alone won't solve the problem. (I am using 'dmake' and I get the same as you.)

    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
      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 <make> test passed. Apparently a lot of the failing tests are marked TODO. As far as Devel::Caller::Perl, the particular module I am trying to install won't accept it as a surrogate dependency.

      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