Hi Donnie,
See answers in-line.
Regards,
Olivier
|-----Original Message-----
|From: Donnie Hale
|
|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.
Technically feasible, but license restrictions forbid development of GPL
software with MSVC7 (.NET). That is also the reason why we asked some
GTK/GLib libraries to be rebuilt with MSVC6 which doesn't have this
restrictive license on GPLed software.
|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.
See my answer to 1.
|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?).
I have been experimenting with the suggestions posted by Stephen Blackheath
in the Feb-Mar period of this year and I was able to compile a working
"almost-native" Ethereal (without plugins, without PCRE support, without
packet capturing support). Unfortunately I'm having problems in building
Ethereal on cygwin for the moment (dynamic library issues) and as such I
cannot be of much help here :(
Another possibility is MinGW but I have no real experience with it. I even
don't know whether someone is till developing with MinGW today.
|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
|
|
|_______________________________________________
|Ethereal-dev mailing list
|Ethereal-dev@xxxxxxxxxxxx
|http://www.ethereal.com/mailman/listinfo/ethereal-dev
|
