Thanks for the feedback...
One thing I forgot to mention/ask is if the SVN Makefile.nmake set the
"_DEBUG" (or "DEBUG", whatever is correct) macro for Wireshark builds so
the default build is a debug version?
If so, on VS 2008 Pro, my VS version, the compile flag for "Runtime
Library" (specifies runtime library for linking) is "/MDd"
(Multi-threaded Debug DLL) for a debug build, not "/MD" (Multi-threaded
DLL).
I remember looking at Makefile.nmake and seeing the option "/MD" being
passed somewhere.
Just thought I'd mention this in case there is a discrepancy between VS
2005 and 2008, or other versions.
Thanks again, -Nathan
On 7/28/2008 5:38 AM, Graham Bloice wrote:
Nathan Jennings wrote:
On 7/25/2008 11:50 AM, Graham Bloice wrote:
Gerald Combs wrote:
According to
http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/
it's possible to use newer versions of Visual C++ to link against
the "classic"
msvcrt.dll instead of msvcr[789]?.dll. This might let us get rid of
some of the
complexity in the current Windows build environment and let us use a
newer
compiler for the official builds.
_______________________________________________
Hmm. The article seems to imply some other complexity as the debug
CRT isn't available so you have to use the one for your compiler
toolchain when debugging. In addition, AFAIK, our CRT problems come
from using compiled binaries from other projects (adns, etc.) that
*currently* use the VS 6 CRT but may switch at any time. I think
we'd still have to ensure all components we use are running with the
same CRT thus the hassles with having to compile them with the CRT of
the developers toolchain.
Thanks for the link to the bug id.
So how does it work now? I mean tracking the CRT for other projects
Wireshark calls into/depends on?
Manually, by fiddling the makefiles and ensuring that the dlls get
rebuilt with the users current toolchain (and crt) for the problematic
cases.
I'm guessing the big ones are GTK/Glib and WinPcap? So do they use
MSVC 2005 EE or, at least, the same CRT?
The problem ones are adns and zlib. GTK relies on Glib and Glib doesn't
import any specific CRT. Using depends
(http://www.dependencywalker.com/) can help you identify the linkages.
If I'm reading/understanding Gerald's link to the post and Graham's
message correctly, then you can link/import to any CRT you'd like
regardless of compiler version (i.e. use CRT v8 with VS 2008 or CRT v7
with VS2005)?
I'm not sure about that. The article seems to be talking about getting
around the issue of linking to a specific CRT that isn't installed on
the target machine. By using the tricks described, it would seem that
an app can be made to use whatever CRT is available. I don't think it
gets around the issue of different components of an app using different
versions of CRT, but I'm assuming Gerald's thinking was that we could
make wireshark itself link to the VC 6 CRT on all toolchains, and hence
have no issues with the third part dll's that also do that.
What I'm getting at is Wireshark could potentially call into three
different CRTs if there were two other binary projects and they were
compiled to two different CRT versions, correct?
I.e. Wireshark CRTv8, GTK/Glib CRTv7, WinPcap MSVCRT.
I don't think you can do that within the same app.
------------------------------------------------------------------------
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-dev