Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I've had trouble installing modules on a Windows XP machine because the Microsoft compiler needs another command line argument to include the manifest at link time, and the resulting DLLs won't load without it.

I found a work-around to run mt.ext manually after build and before install.

But, I ran into one that won't install because it tries to test things first. So, I really must get the various rebuild modules to work right. Why hasn't this bitten everyone before?

Well, maybe it's easier just to tell it to use MINGW. So, of the several compilers that may be installed, how does the Perl install stuff know which one to use, or that such are even available?

Replies are listed 'Best First'.
Re: installing modules with XS on Windows 64-bit
by syphilis (Archbishop) on May 04, 2009 at 22:25 UTC
    Well, maybe it's easier just to tell it to use MINGW

    If it's a 32-bit build of perl, then that's not a bad idea. But if you're running a 64-bit build of perl, then using MinGW64 with it is going to be very difficult.

    Telling us that you have "Windows 64-bit" is not, by itself, all that helpful. We also need to know whether it's a 64-bit or 32-bit build of perl.

    Updating ExtUtils::MakeMaker might also fix your problem - I'm not sure, but the manifest issue (or at least some part of it) has received attention in ExtUtils-MakeMaker-6.50 .

    Cheers,
    Rob
[reply]
      Sorry, yes, 64-bit build of Perl. Otherwise the OS being 64-bit would not matter except for obscure file path issues.

      Thanks for the pointer on MinGW64. Why is that difficult to use? The release notes that came with Perl state that Microsoft Visual and Mingw are the two supported compilers. I guess neither is correct. Which makes me wonder where all the standard modules that it shipped with came from?

      —John

[reply]
        Thanks for the pointer on MinGW64. Why is that difficult to use?

        I don't have an informed answer, and there's a chance that it might not be as hard as I envisage, but on the few occasions I've tried, I always strike problems. For example, MinGW32 can link to a 32-bit Perl/lib/CORE/perl510.lib. But MinGW64 seems unable to link to a 64-bit Perl/lib/CORE/perl510.lib. And whereas VC6 and VC7 can link to MinGW32-built libraries, I can't get the 64-bit Platform SDK compiler to link to MinGW64-built libraries.

        With 32-bit builds of ActivePerl, either Visual Studio or MinGW will work straight out of the box (and it's simply a case of whichever compiler is found, is the one that will be used). If the release notes say that the 64-bit build of ActivePerl can also use either Visual Studio or MinGW, then I think those notes need amending.

        Which makes me wonder where all the standard modules that it shipped with came from?

        That 64-bit build of ActivePerl (including the standard modules) was built using the "Microsoft Platform SDK for Windows Server 2003 R2" compiler. You can use that compiler to build other modules for 64-bit ActivePerl.

        Cheers,
        Rob
[reply]
Re: installing modules with XS on Windows 64-bit
by jettero (Monsignor) on May 04, 2009 at 20:05 UTC

    I think this solves your problem. From the cpan shell: o conf make_arg -blarg -blarg

    I'm a little surprised it doesn't default to it through the Config module. Perhaps it would help to build your own perl as well, or did you?

    -Paul

[reply]
[d/l]
      The cpan shell gets stuck on "fetching with LWP" so I was downloading it, unpacking, etc. without cpan. Although I set the http_proxy variable, it still won't work. Using Firefox I don't have to type any kind of password to get out, so I'm at a loss.

      Is there a way to tell CPAN to use the tar.gz files I've downloaded already?

[reply]
        Unpack the dist, cd into it and "cpan ." It works on later CPANs.

        -Paul

[reply]

Back to Seekers of Perl Wisdom