There's more than one way to do things | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
What to do?
File bug reports against ActivePerl. It's not very professional that they automatically set out "to install dmake and the MinGW gcc compiler using Perl Package Manager" on their X64 builds of perl when: 1) They know that no suitable ppm package exists; 2) They know that the x64 builds of ActivePerl won't work with dmake and MinGW anyway. (Incidentally, for anyone interested, I can provide fixes to x64 Activeperl that allow it to work fine with dmake and the 64-bit MinGW compiler - ie allow it to work just like the 32-bit builds.) The 'libConfig.pm' error crops up from time to time ... but not so often as to allow me to recall (with certainty) the cause of it. I *think* it happens when perl Makefile.PL writes a Makefile for nmake to process, but then the user throws a spanner in the works by running dmake instead. It's important that the flavour of make that you run is whatever is reported by perl -V:make Iff this module that you're trying to build is pure perl, then there's a chance that you can do it with dmake alone iff you follow these steps: 1) Prepend the location of dmake.exe to (the beginning of) your PATH env var; 2) Check that perl -V:make reports 'dmake' (or '\full\path\to\dmake.exe', as the case may be); 3) In the top level source folder, remove the file named Makefile 4) In the top level source folder run perl Makefile.PL followed by dmake test followed by dmake install 5) For me the dmake install can take a minute or so before anything happens ... be patient. Cheers, Rob In reply to Re: Installing WordNet::QueryData on Win7/Perl64
by syphilis
|
|