["yin sun" <sunyin51@xxxxxxxxx>]

my experience is, try the same build command again, it may pass and move further then failed at other place. Then you can try again. I post the problem before in the mailing list, seems nobody has the same problem. I have to think my build environment is not clean or my notebook is too slow (NC8000).

/Yin

On 9/7/07, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:

Michael Allport wrote:
>
> I apologize if this is not the correct forum, but I've got a question …
>
I'll only reply the once, even though you seem to have posted the same
message twice.
>
>
>
>
>
> I am using Microsoft Visual Studio 2005 Standard Edition on a Windows
> 2000 (5.00.2195 Service Pack 4) laptop PC.
>
>
>
> When I run through the build process, some make files can find items
> like perl, sed, and xcopy …. then they cannot.
>
>
>
> Even more frustrating is I can run the commands manually that 'just
> failed' in the build process.
>
>
>
> For example, the following snippet of make output shows perl being not
> found, then I can run the command my self.
>
>
>
> The interesting thing is, I have no problem building on a Windows XP
> Home Edition environment (running through the same commands and using
> the same software).
>
>
>
> Please help.
>
>
>
>
>
> ---------- snippet begin ------------
>
>
>
You aren't showing the initial command you used to start the build
process.  That would help.
>
>
>
> … the build process steps into the dissectors and cannot find perl,
> but I can run manuall…
>
>
>
>
>
>
>
>
>
> Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
>
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>
>
> 'dfilter.lib' is up-to-date
>
>         cd ..
>
>         cd wslua
>
>         "C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe"
> /                   -f Makefile.nmake
>
>
>
> Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
>
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>
>
> 'wslua.lib' is up-to-date
>
>         cd ..
>
>         cd dissectors
>
>         "C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe"
> /                   -f Makefile.nmake
>
>
>
> Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
>
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>
>
>         perl process-x11-fields.pl <x11-fields
>
> 'perl' is not recognized as an internal or external command,
>
> operable program or batch file.
>
> NMAKE : fatal error U1077: 'perl' : return code '0x1'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
> 8\VC\BIN\nmake.exe"' : return code '0x2'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
> 8\VC\BIN\nmake.exe"' : return code '0x2'
>
> Stop.
>
>
>
> C:\wireshark>
>
>
>
>
>
> ****** I can manually run the command that failed .. .
>
>
>
> C:\wireshark\epan\dissectors>
>
> C:\wireshark\epan\dissectors>perl process-x11-fields.pl <x11-fields
>
Which implies that the environment for nmake is different from your
command shell.
>
>
>
> C:\wireshark\epan\dissectors>"C:\Program Files\Microsoft Visual Studio
> 8\VC\BIN\nmake.exe" /                   -f Makefile.nmake
>
And this is really odd.  If you have your build environment set
correctly, you should really be able to run nmake *without* supplying a
path.

Have you run "vcvars32.bat" from the same "bin" directory as nmake.exe
is found in?  That sets the paths for VC.
>
>
>
It could help if you post the output of "path" from your build
environment.  What is the result of "nmake -f makefile.nmake verify_tools" ?

--
Regards,

Graham Bloice

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev