Can't install Perl module with dmake utility

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

Dear All:

I'm trying to install module MATH::GLPK::SOLVE by using the 'gcc' compiler along with 'dmake'utiliy and can't figure out how to fix dmake: Error code 129. It seems the 'link' command is not valid.

Please shed some light. I'm running Win7 with perl 5, version 14, subversion 2 (v5.14.2) built for MSWin32-x64-multi-thread and I prefer to use gcc as opposed to Visual Studio 2008.

D:\installs\GLPK Linear Programming\Math-GLPK-Solve-0.07>dmake
cp Solve.pm blib\lib\Math\GLPK\Solve.pm
cp demo.pl blib\lib\Math\GLPK\demo.pl
cp Solve.pod blib\lib\Math\GLPK\Solve.pod
gcc -c  -IC:/gnuwin32/src       -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRIC
+T -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE 
+-DPERL_IMPLICIT_CONTE
XT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DHASATTRIBUTE -fno-strict-aliasin
+g -mms-bitfields -O2        -DVERSION=\"0.07\"    -DXS_VERSION=\"0.07
+\"  "-IC:\Perl64\lib\
CORE"   GLPK_wrap.c
GLPK_wrap.c: In function 'SWIG_Perl_ConvertPtr':
GLPK_wrap.c:710:15: warning: cast to pointer from integer of different
+ size [-Wint-to-pointer-cast]
GLPK_wrap.c: In function 'SWIG_Perl_GetModule':
GLPK_wrap.c:907:22: warning: cast to pointer from integer of different
+ size [-Wint-to-pointer-cast]
GLPK_wrap.c: In function 'SWIG_Perl_SetModule':
GLPK_wrap.c:920:3: warning: cast from pointer to integer of different 
+size [-Wpointer-to-int-cast]
Running Mkbootstrap for Math::GLPK::Solve ()
C:\Perl64\bin\perl.exe -MExtUtils::Command -e "chmod" -- 644 Solve.bs
C:\Perl64\bin\perl.exe -MExtUtils::Mksymlists \
     -e "Mksymlists('NAME'=>\"Math::GLPK::Solve\", 'DLBASE' => 'Solve'
+, 'DL_FUNCS' => {  }, 'FUNCLIST' => [], 'IMPORTS' => {  }, 'DL_VARS' 
+=> []);"
dlltool --def Solve.def --output-exp dll.exp
link -o blib\arch\auto\Math\GLPK\Solve\Solve.dll -Wl,--base-file -Wl,d
+ll.base -mdll -L"C:\Perl64\lib\CORE" GLPK_wrap.o   C:\Perl64\lib\CORE
+\perl514.lib C:\MinGW
\lib\libkernel32.a C:\MinGW\lib\libuser32.a C:\MinGW\lib\libgdi32.a C:
+\MinGW\lib\libwinspool.a C:\MinGW\lib\libcomdlg32.a C:\MinGW\lib\liba
+dvapi32.a C:\MinGW\li
b\libshell32.a C:\MinGW\lib\libole32.a C:\MinGW\lib\liboleaut32.a C:\M
+inGW\lib\libnetapi32.a C:\MinGW\lib\libuuid.a C:\MinGW\lib\libws2_32.
+a C:\MinGW\lib\libmpr
.a C:\MinGW\lib\libwinmm.a C:\MinGW\lib\libversion.a C:\MinGW\lib\libo
+dbc32.a C:\MinGW\lib\libodbccp32.a C:\MinGW\lib\libcomctl32.a C:\MinG
+W\lib\libmsvcrt.a dll
.exp
'link' is not recognized as an internal or external command,
operable program or batch file.
dmake:  Error code 129, while making 'blib\arch\auto\Math\GLPK\Solve\S
+olve.dll'
[download]

Thanks for your advise.

Comment on Can't install Perl module with dmake utility Download Code

Replies are listed 'Best First'.
Re: Can't install Perl module with dmake utility by davido (Cardinal) on Feb 15, 2012 at 07:26 UTC
You mentioned, "dmake", but have you actually used the mantra? `perl Makefile.PL dmake dmake test dmake install` [download] In this case, did you run Makefile.PL before typing `dmake`? It's tricky putting together a good rock-solid distribution that incorporates C extension code via XS, Inline::C, or SWIG. It's possible that Makefile.PL hasn't been designed to facilitate a nice squeaky-clean install across a broad range of system configurations. To me it doesn't inspire much confidence when an extension module linking in C code isn't on CPAN. Being on CPAN is not a mark of quality by any means, but extension code can be difficult to build into a distribution portably. Again I want to reiterate that being on CPAN isn't some seal of approval, nor is it impossible to find good modules outside of CPAN. However, when a module finds its way onto CPAN an army of smoke testers put it through its test suite and issue PASS/FAIL reports for hundreds of different systems. As a module author, it's one thing to assure that ones module passes its test suite on your system, or a handful of available test beds. But it's another thing entirely to verify that it passes on hundreds of systems using different configurations and combinations of tool-chains. By not being on CPAN, this particular module has probably not seen such exhaustive smoke testing, and that is something that extension modules that incorporate C via SWIG, XS, Inline, etc. really need; lots of testing. Furthermore, you as a user have no good way of knowing whether or not an extension module like this is likely to install and function on your system since you can't look at a CPAN tester's matrix to see how others have fared with similar configurations. If you could look at such a tool, you would be able to quickly determine whether you're in a relative minority of individuals with Windows who are unable to install, or whether your situation is a common point of failure. I assume you've read this: http://qosip.tmit.bme.hu/~retvari/Math-GLPK-Solve.html, where the author states: The most prominent problems you may experience with this module is that (a) you run some operating system other than NIX, most notably, Win32. You have a good chance to make the module work in this case too, however, be prepared that you are alone out there. There are additional install instructions here: http://qosip.tmit.bme.hu/~retvari/perl-modules/readme, including the friendly advice, "If you have problems or suggestions, please, contact me (retvari -AT- tmit -dot- bme -dot- hu)!*". Dave	[reply] [d/l] [select]
Re: Can't install Perl module with dmake utility by VinsWorldcom (Prior) on Feb 15, 2012 at 13:59 UTC
I'm using Strawberry Perl on Win7 with gcc / dmake. I can't find Math::GLPK::Solve on CPAN, only Math::LP::Solve so can't test if it does / doesn't work with my environment. By your Perl directory (Perl64) it seems you're using ActiveState Perl? ActiveState does 'prefer' the MS compiler tools and if your path environment variable is not set correctly, it will pick those up. Make sure your MinGW path is before your MS Visual C path in your PATH environment variable. I've had issues when I used to use ActiveState (and also preferred the gcc / dmake utilities) that when compiling modules, cl / nmake was use instead of gcc / dmake. For what its worth, I can't find link.exe on my system anywhere in my path - surely not in the Strawberry distribution which includes a MinGW compiler.	[reply]