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

Monks,

I am trying to build NetAddr::IP on a Windows 2003 64 bit machine, so I can use it to do some checking with IPv6 addresses, and be able to handle IPv4 addresses. I am getting a problem with my setup that will not let me build this properly, either through CPAN shell or performing the Makefile manually.

Here are the steps I am following:

Downloaded the source file from CPAN and expanded it to a local directory.

I set up my local machine's environment with a script file to get my environment right, since I am using nmake from Visual Studio. This came from an earlier solution on building Socket6 from Syphilis.

set INCLUDE= "E:\SDK2003\SetEnv.cmd" /X64 /RETAIL

Then I run perl Makefile.PL and do not see any comments about missing modules, everything looks fine.

Then I run nmake and I get the following:

C:\work\NetAddr-IP-4.007>nmake /D /I /F Makefile Microsoft (R) Program Maintenance Utility Version 7.00.8882 Copyright (C) Microsoft Corp 1988-2000. All rights reserved. Makefile.PL Mon Aug 14 11:36:06 2006 E:\Perl64\lib\Config.pm Thu Sep 20 08:50:44 2007 E:\Perl64\lib\CORE\config.h Thu Sep 20 08:50:44 2007 Makefile Tue Jan 22 11:38:27 2008 Makefile.PL Mon Aug 14 11:36:06 2006 Makefile.PL Mon Aug 14 11:36:06 2006 Makefile.PL Mon Aug 14 11:36:06 2006 Makefile.PL Mon Aug 14 11:36:06 2006 Makefile.PL Mon Aug 14 11:36:06 2006 Makefile.PL Mon Aug 14 11:36:06 2006 Makefile.PL Mon Aug 14 11:36:06 2006 Makefile.PL Mon Aug 14 11:36:06 2006 blibdirs target does not exist IP.pm Wed Jun 06 16:43:38 2007 pm_to_blib target does not exist cp IP.pm blib\lib\NetAddr\IP.pm AutoSplitting blib\lib\NetAddr\IP.pm (blib\lib\auto\NetAddr\IP) nmake -f Makefile all -nologo cp Lite.pm ..\blib\lib\NetAddr\IP\Lite.pm nmake -f Makefile all -nologo ./siteconf "cl" ".c" ".obj" ".exe" "-nologo -GF -W3 -MD -Zi -D +NDEBUG -Ox -GL -Wp64 -fp:precise -DWIN32 -D_CONSOL E -DNO_STRICT -DHAVE_DES_FCRYPT -DWIN64 -DCONSERVATIVE -DNO_HASH_SEED +-DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_I MPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX +" "" "oldnames.lib kernel32.lib user32.lib gdi32.l ib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleau +t32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib bufferoverflowU.lib msv +crt.lib" '.' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: '.' : return code '0x1' Stop. NMAKE : fatal error U1077: 'E:\SDK2003\Bin\nmake.exe' : return code '0 +x2' Stop. cd .. Makefile Tue Jan 22 11:38:27 2008 IP.pm Wed Jun 06 16:43:38 2007 htmlifypods target does not exist makemakerdflt target does not exist

I can see where in the Makefile.PL the siteconf line comes from, but I don't see where there is a "." that would be setting off an error. Even trying to run nmake with the IGNORE option did not work, it seemed as if running it with /I would allow it to ignore "." errors, but there must be something I am missing. Here is the siteconf line from the Makefile.PL.

localStuff.h : ./siteconf "$(CC)" ".c" "$(OBJ_EXT)" "$(EXE_EXT)" "$(CCFLAGS)" "$( +LDflags)" "$(LDLOADLIBS)" |; }

Does anyone have a clearer picture than me on where the error is coming from?

Thanks

Replies are listed 'Best First'.
Re: NetAddr build problem on Windows 2003 Server
by BrowserUk (Patriarch) on Jan 22, 2008 at 17:19 UTC

    ./siteconf looks to the windows shell like a command . with a switch /siteconf. Try modifying the makefile to use a backslash instead: .\siteconf.

    I've no idea what siteconf is, but assuming that it is a win32 executable (or perl script ot bat file) in the current directory, that should allow you to get a little further.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Since on windows the current directory is in $PATH per default, you don't need the ./ at all (just a guess, I don't have a win* to test).
        Since on windows the current directory is in $PATH per default,

        Agreed that is normal, but given all the machinations that the Perl make files do, it almost impossible to be sure what will be in the environment variables at any given point in the build process.

        It is very likely that (Ahem! :) %PATH% has ben futzed with. And entirely possible that some other directory has been prepended or that '.' has been omitted entirely.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        The current directory is not in the Path environment variable by default on Windows. It is searched before the environment variable is used, along with a bunch of other directories. The default search is:
        1. The directory from which the application loaded.
        2. The current directory*
        3. The system directory (eg. C:\WINDOWS\system32)
        4. The 16-bit system directory. (eg. C:\WINDOWS\system)
        5. The Windows directory. (eg. C:\WINDOWS)
        6. The directories that are listed in the PATH environment variable.

        * The current directory position is "moved" to number 5 on 2003 Server, and this may also be done on XP by tweeking the registry.
        I tried that and it did not work, I had considered that maybe it was just trying to get something in the same directory but that did not seem to be the case. I got a different error then:
        'siteconf' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'siteconf' : return code '0x1' Stop.
        Any modification of siteconf generates errors that its not recognized as an internal or external command.
        'siteconf' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'siteconf' : return code '0x1' Stop.

        I hadn't focused too much on that one, but I'll see what I can find out there. siteconf seems to be a Perl file.

        # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.53 and edited for this module 9-22-03 ... # the command line must contain # # siteconf CCname Cfile_ext OBJext EXEext "Cflags" "LDflags"
        This is actually located in NetAddr-IP-4.007\Lite\Util if you look at the expanded package.

      I decided to try a new tack with this and use the -noxs option, which builds without the XS files and makes the implementation pure Perl. This seemed to go ok, and it looks like I have a work around for now, or until I can determine why siteconf can't be run; though whether its because its a shell script that is not interpreted correctly or not I have no idea. I'm not that proficient with make on Windows.

        I can determine why siteconf can't be run; though whether its because its a shell script that is not interpreted correctly...

        As pointed out by anonymonk elsewhere in this thread siteconf is a unix shell script. And unless you are using cygwin (and from your use of nmake you aren't), it will not run under windows.

        That strongly suggests that the makefile being generated is not being generated for windows. Either becaus you are not configuring correctly or because the makefile.pl is not set up to generate windows make files.

        I'd strongly suggest that you follow the other anonymonk post that linked to a pre-built ppm and install it that way.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: NetAddr build problem on Windows 2003 Server
by Anonymous Monk on Jan 23, 2008 at 14:36 UTC
      yes, but these don't work on 64 bit Windows.