I believe this has been alluded to in other threads, but just in case...
There are numerous 3rd party libraries on which ethereal depends. I've
downloaded them all and run "dumpbin /imports" against many of them. As far
as I can tell, they are all dependent on "MSVCRT.DLL" - the
dynamically-linked version of the C runtime library. As the majority of
these libraries are distributed as DLLs, that makes sense. Unless incredibly
tight boundaries are set up between the services that a DLL provides and its
callers, it is generally unsafe to statically link the C RTL into a DLL.
Doing so guarantees that any binaries that call it will have a different
instance of the C RTL when they run. This impacts things like memory
management - each RTL instance has its own heap, for example; so you can't
allocate memory in one and be sure you can safely free it in another.
My point is that this same constraint applies if one were to attempt to
build ethereal with the new command-line tools from MS, statically linking
the RTL. You'd have a .exe with its own RTL inside the binary; and it would
be using numerous DLLs which would be sharing the RTL provided by
MSVCRT.DLL.
Unfortunately, as I discovered recently, even if you try to compile ethereal
against the DLL flavor of the RTL, the latest tools (VS.NET 2003 and, I'm
sure, the command line tools), you still have an equivalent problem. That's
because the latest tools require "MSVCRT7.DLL", which is the redistributable
C RTL that MS now wants you to ship with your apps and install in the app's
"bin" directory. In that case, you'd have a .exe using MSVCRT7.DLL's RTL and
all of the 3rd party DLLs using MSVCRT.DLL's RTL. Even if it worked a lot of
the time, I'd expect numerous confounding edge cases that wouldn't be worth
trying to support.
Best I can tell, there are only a few correct solutions:
1) Recompile all of the 3rd party libraries w/ the new tools, building them
as DLLs that require MSVCRT7.DLL. Then build ethereal the same way. This
keeps things closest to how they are now (pretty much all 3rd party
libraries as DLLs). The problem could occur again if/when the "latest" C RTL
is called MSVCRT8.DLL (or some such). To work around that, you'd have to
have different builds of the 3rd party DLLs for each flavor of the C RTL DLL
that should be supported.
2) Recompile all of the 3rd party libraries w/ the new tools as static
libraries that use the static C RTL. Build ethereal with those static
libraries and the static C RTL. Deal with real large .exe's. This is the
most future-proof, as there's no concern about C RTL issues except when
dealing with the expected symbols at link time. Assuming the link succeeds
(and something ridiculous hasn't happened like a change in calling
conventions), the binary will work.
3) Stick w/ MSVC6 ad infinitum. Even that has its problems, apparently, as
I'll likely have to get into in a near-future message.
4) Continue down the path of some other threads and make the cygwin build of
ethereal the first-class windows citizen. That probably has its issues, too.
FWIW...
Donnie
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Biot Olivier
Sent: Tuesday, April 20, 2004 7:35 AM
To: 'Ethereal development'
Subject: RE: [Ethereal-dev] Is it possible to build Ethereal with the
MSVC++ Toolkit 2003 and nmake 1.5?
|-----Original Message-----
|From: Andrew Hood
|
|Biot Olivier wrote:
|| Hi list,
||
|| I was happily surprised to know that Redmond decided to
|distribute the
|| command-line "VC++ Toolkit 2003" and that its EULA does not
|seem to be as
|| restrictive as the fully-fledged VC++ 2003.
||
|| This raises two questions to me:
||
|| 1. Are we allowed to build and "ship" Ethereal built with
|the VC++ Toolkit
|| 2003, meaning that we are not infringing the EULA?
||
|| 2. How do we technically proceed as I understood from previous
|postings that
|| there were incompatibilities between libraries compiled with
|different
|| versions of MSVC++?
|
|IIRC the blurb said there were only static libraries included in the
|free version. Hence there should be no library issues, but will create
|big executables.
I see. However this may be an interesting path to walk, no? If I look at the
size of the binaries and executables (I manually added NMAKE 1.5 from the
link posted previously).
$ cd /cygdrive/c/Program\ Files/Microsoft\ Visual\ C++\ Toolkit\ 2003/
$ ls -l bin/*
-rwx------+ 1 Administ mkgroup- 5056 Sep 16 1994 bin/NMAKE.ERR
-rwx------+ 1 Administ mkgroup- 65536 Sep 16 1994 bin/NMAKE.EXE
-rwx------+ 1 Administ mkgroup- 693 Jun 20 1995 bin/README.TXT
-rwx------+ 1 Administ mkgroup- 933888 Feb 21 2003 bin/c1.dll
-rwx------+ 1 Administ mkgroup- 2207744 Feb 21 2003 bin/c1xx.dll
-rwx------+ 1 Administ mkgroup- 1867776 Feb 21 2003 bin/c2.dll
-rwx------+ 1 Administ mkgroup- 86016 Feb 21 2003 bin/cl.exe
-rwx------+ 1 Administ mkgroup- 145 Feb 21 2003 bin/cl.exe.config
-rwx------+ 1 Administ mkgroup- 719360 May 31 2002 bin/dbghelp.dll
-rwx------+ 1 Administ mkgroup- 647168 Feb 21 2003 bin/link.exe
-rwx------+ 1 Administ mkgroup- 145 Feb 21 2003 bin/link.exe.config
-rwx------+ 1 Administ mkgroup- 73728 Mar 18 2003 bin/msobj71.dll
-rwx------+ 1 Administ mkgroup- 241664 Feb 21 2003 bin/mspdb71.dll
-rwx------+ 1 Administ mkgroup- 499712 Mar 18 2003 bin/msvcp71.dll
-rwx------+ 1 Administ mkgroup- 348160 Feb 21 2003 bin/msvcr71.dll
$ ls -l lib/*
-rwx------+ 1 Administ mkgroup- 191866 Aug 10 2002 lib/kernel32.lib
-rwx------+ 1 Administ mkgroup- 2707332 Feb 21 2003 lib/libc.lib
-rwx------+ 1 Administ mkgroup- 3023122 Mar 18 2003 lib/libcd.lib
-rwx------+ 1 Administ mkgroup- 94208 Mar 18 2003 lib/libcd.pdb
-rwx------+ 1 Administ mkgroup- 2937240 Feb 21 2003 lib/libcmt.lib
-rwx------+ 1 Administ mkgroup- 3604302 Feb 21 2003 lib/libcp.lib
-rwx------+ 1 Administ mkgroup- 4433724 Mar 18 2003 lib/libcpd.lib
-rwx------+ 1 Administ mkgroup- 225280 Mar 18 2003 lib/libcpd.pdb
-rwx------+ 1 Administ mkgroup- 3654594 Feb 21 2003 lib/libcpmt.lib
-rwx------+ 1 Administ mkgroup- 18618 Feb 20 2003 lib/mscoree.lib
-rwx------+ 1 Administ mkgroup- 69512 Feb 21 2003 lib/oldnames.lib
|The incompatible library warnings usually refer to the VC7 version of
|MSVCRT.DLL, which M$ say you should distribute with your application in
|its install directory, and NOT put in the system. That seems to be the
|one that triggers all the license problems.
We can avoid this problem by statically linking the provided .lib objects,
right?
Regards,
Olivier
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
