Wireshark · Ethereal-dev: Re: [Ethereal-dev] Is it possible to build Ethereal with the MSVC++Toolkit 2003 and nmake 1.5?

["Olivier Biot" <ethereal@xxxxxxxxxx>]

Ahh... looks like the MSVC++ Toolkit cannot be used then to build
Ethereal :(

Regards,

Olivier

----- Original Message ----- 
From: Donnie Hale

| 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
|
|
| _______________________________________________
| Ethereal-dev mailing list
| Ethereal-dev@xxxxxxxxxxxx
| http://www.ethereal.com/mailman/listinfo/ethereal-dev