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 > [email protected] > https://wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
