Ethereal-dev: RE: [Ethereal-dev] Re: Support for building under Visual Studio 2k3
Mike,
To compile with the .NET SDK, you'll have to install the platform SDK
(available for free).
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
Your linking problem is caused by "bad" parameters in config.nmake. I
never sent a patch to fix this because I'm not sure whether or not it
impacts VS6 compilation.
I replaced:
1) LOCAL_CFLAGS=/Zi /W3 by LOCAL_CFLAGS= /Zi /DWIN32 /W3
2) LOCAL_LDFLAGS=/DEBUG by LOCAL_LDFLAGS=/DEBUG /DEFAULTLIB:msvcrt
/NODEFAULTLIB:libc
While compiling plugins, you might also encounter problems. For these
plugins, in the Makefile.nmake file change
LDFLAGS = /NOLOGO /INCREMENTAL:no /MACHINE:I386 $(LOCAL_LDFLAGS)
by
LDFLAGS = /NOLOGO /INCREMENTAL:no /MACHINE:I386
...I know, that's not very clean ;-)
At last, don't forget to include a line such this:
File "c:\program files\Microsoft Visual Studio .NET
2003\Common7\IDE\msvcr71.dll"
... in your ethereal.nsi script (if you want to create an installer)
Let me know if this fixed all your problems.
Good luck!
Laurent
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Mike Perry
Sent: Wednesday, February 02, 2005 1:41 AM
To: Ethereal development
Subject: [Ethereal-dev] Re: Support for building under Visual Studio 2k3
Thus spake RABRET Laurent RD-MAPS-ISS
(laurent.rabret@xxxxxxxxxxxxxxxxx):
> Yes, ZLIB is the only external library you have to recompile. I've
also
> installed VS .NET 2k3 at work and succeed in compiling and using
> ethereal with this release. However, I do use msvcr7x.dll. Maybe the
> problem you encounter concerns a mismatch regarding important
libraries.
> You might have a look on this message I sent 18 months ago. It helped
> some folks resolving this issue.
So I rebuilt zlib-1.2.1 and verified with depends.exe that it's linked
against the new msvcr71.dll, and copied it to c:\ethereal-win32-libs
and the ethereal build still failed with 44 linker errors along the
same lines as these during the link stage right after
ascend-scanner.c:
lanalyzer.obj : error LNK2001: unresolved external symbol __imp__fwrite
libpcap.obj : error LNK2001: unresolved external symbol __imp__fwrite
netmon.obj : error LNK2001: unresolved external symbol __imp__fwrite
5views.obj : error LNK2019: unresolved external symbol __imp__time
referenced in function __5views_dump_close
network_instruments.obj : error LNK2019: unresolved external symbol
__imp__time referenced in function _network_instruments_dump_open
5views.obj : error LNK2019: unresolved external symbol __imp___tzset
referenced in function __5views_dump_close
ascend-scanner.obj : error LNK2001: unresolved external symbol
__imp__strtoul
airopeek9.obj : error LNK2019: unresolved external symbol __imp__strtoul
referen ced in function _wtap_file_read_number
iptrace.obj : error LNK2001: unresolved external symbol __imp__strtoul
toshiba.obj : error LNK2001: unresolved external symbol __imp__strtoul
vms.obj : error LNK2001: unresolved external symbol __imp__strtoul
I've actually managed to hack my way though a full build of 0.10.9
using the msvcrt.dll from Visual Studio 6, and those errors were
eliminated by switching dlls. I suspect the problem here is that the
glib lib is still using the old dll, regardless of what zlib uses..
I've also noticed that neither the .NET SDK nor the VS Toolkit contain
windows.h (and probably lots of other include files?) Did you use
MinGW's version or something?
--
Mike Perry
Mad Computer Scientist
fscked.org evil labs
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
