Re^2: NetAddr build problem on Windows 2003 Server
by moritz (Cardinal) on Jan 22, 2008 at 17:21 UTC
|
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). | [reply] [d/l] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
Your list looks correct for (one variation of) dll search path algorithm, but I have failed to find anything to support it as the executable search path?
Or anything that suggests the two are the same. For example, when looking for an exectuable to execute, what does item 1 in your list mean?
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.
| [reply] |
|
|
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.
| [reply] [d/l] |
|
|
| [reply] |
|
|
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.
| [reply] [d/l] [select] |
Re^2: NetAddr build problem on Windows 2003 Server
by gokuraku (Monk) on Jan 23, 2008 at 15:01 UTC
|
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.
| [reply] |
|
|
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.
| [reply] [d/l] [select] |
|
|
I think you are right, the Makefile doesn't work for Windows adequately, or in my case 64 bit Windows. I'll stay with the -noxs version since there are no listing for prebuild 64 bit ppm packages in the ppm repositories
| [reply] |