Yes - that's the command prompt environment I used.
After I sent the email, I stumbled on what's likely the cause of the
problem, though I haven't had time to look further. Starting with VS.NET
2003, MS has sort of deprecated use of apps linking against the stock
MSVCRT.DLL that comes w/ the OS (in the "system32") directory. Specifying
"MSVCRT.LIB" (or MSVCRTD.LIB for debug) to the linker implies that the
binary requires MSVCR71(D).DLL at runtime. MS specifies that MSVCR71.DLL
should be redistributed with your app and *not* placed in the "system32"
directory at install time - it should go in the same directory with the app
binaries. This is something I learned a long time ago developing apps on
Windows - I always put the copies of the right versions MSVCRT and MFC
.dll's in the app runtime directories - avoids a little bit of DLL hell.
For ethereal, that means that all of the .exe's and .dll's built via the set
of .nmake make files end up requiring that MSVCR71 DLL (as can be seen by
dumpbin /imports). However, all the .dll's that come in the 3rd party
libraries used to do the builds expect MSVCRT.DLL. At runtime, the different
.dll's accessing different MSVC .dll's likely makes the whole environment
incompatible.
Given that problem, I can think of 4 solutions (at least that don't border
on the radical):
1. Rebuild all the 3rd party libraries with VS.NET 2003. If this is even
possible, it's likely a pain in the butt. It's probably the purest approach
given that the version of VC that seems to be relied upon for ethereal is
getting a little old.
2. Generate an import library from the MSVCRT.DLL and link against that.
Digital Mars has an implib utility that can generate the import library.
Obviously, that approach would need some testing.
3. Stick with the older version of VC to build ethereal ad infinitum. I
don't like the idea of having 2 VC compiler suites installed, but it's
probably the way to get things working the quickest for me.
4. I saw a message on one of the list archives that someone had built a
"native" Windows version of ethereal using cygwin (i.e. no cygwin.dll
required). If we could formalize that approach in the source distribution,
that would be a pretty good solution. I don't know what C RTL that version
requires (a GNU C RTL DLL?).
Thanks for bearing with me,
Donnie
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Graham Bloice
Sent: Tuesday, April 13, 2004 4:05 AM
To: Ethereal development
Subject: RE: [Ethereal-dev] Questions & Lessons building on Win32
<SNIP>
> It's getting late at this point - I've got to call it a night. :)
> Any input
> would be appreciated.
Did you run vsvars32 ? This is the .Net equivalent of vcvars32 which sets
up the command line build environment. Note that building Ethereal with
VS.Net isn't particularly supported because, I believe, of redistribution
problems with the msvc dll's
Graham Bloice
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
