Ethereal-dev: RE: [Ethereal-dev] Is it possible to build Ethereal with the MSVC ++ Toolkit 200

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Biot Olivier <Olivier.Biot@xxxxxxxxxxx>
Date: Tue, 20 Apr 2004 13:35:18 +0200
|-----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