On 29/08/2011 19:52, Ed Beroset wrote:
> Guy Harris wrote:
>> I think at least once I've had my path set incorrectly when building Wireshark on Windows, and getting the wrong command run - a Cygwin port of some UN*X command being run instead of some other Windows tool that had the same name but was a different tool. I think that's happened for me at least once with "mt" - and, if not me, with somebody else asking wireshark-dev about it.
>>
>> That's why I wanted you to run "where mt.exe", to see whether it was picking up Cygwin's "mt". From the output you got, it appears that it wasn't picking up Cygwin's "mt", so that's apparently not the cause of the problem.
> For what it's worth, I've definitely had path trouble building Wireshark on Windows (with Cygwin installed and in the path) and have found that the Cygwin-supplied "which" command is very helpful to sort this out. On my system, I use a batch file that explicitly sets the path (rather than the often recommended method of appending to the path) to avoid exactly this kind of problem. It looks like this:
>
> set PATH=...(long explicit path with Visual Studio stuff first)
> set WIRESHARK_TARGET_PLATFORM=win32
> call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
> title Command Prompt (VC++ 2008)
>
> Ed
>
For what it's worth Windows already supplies the "where" command that locates
files matching a specified search pattern. The search is done in the current
directory and in the paths specified by the PATH environment variable. I've
often wondered why MS named it "where" but can only come up with the guess
that you'll be using it when you have path issues, and possibly the old POSIX
compatibility stuff (SFU or SUA) installed so *needed* to keep it different
from "which". Of course, it's somewhat hard to retrain the brain\keyboard
interface to type "where" when you mean "which" so my PowerShell profile has
an alias for that. In addition, PowerShell already aliases "where" to
"Where-Object" that does something else entirely.
The various VS and SDK toolchain batch setup files (vcvarsall.bat,
vcvars32.bat SetEnv.CMD) all prepend the MS toolchain paths onto the existing
path so it really shouldn't matter whether you have Cygwin on your path or
not, the MS toolchain executables should be found first as long as you don't
mess with the path after running the toolchain setup file. Config.nmake
appends the Cygwin bin folder to the PATH var for compilation purposes.
Note that vcvarsall.bat is just a convenient way to invoke the required batch
file for your particular architecture if you need to choose, and defaults to
x86 which then calls the vcvars32.bat as specified in the developers guide.
Regards,
Graham Bloice