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.
You can, but you have to make sure any CRT calls that affect the CRT's private
data (such as malloc and free) use the same CRT. This is why we build our own
zlib and ADNS DLLs.
It would be nice to have a Windows build environment that could do all of the
following:
Link against the "correct" CRT. So far we've avoided this problem in the
official builds by using Visual C++ 6. However, the value of "correct" is
changing. Some of the libraries we depend might stick with MSVCRT.DLL
indefinitely, but some (such as Lua) have moved on to newer CRT versions.
Provide a development environment that's newer than dirt for official builds
(such as Visual C++ 2008 or 2005). Visual C++ 6 is no longer supported, and
generates less safe code compared to newer versions.
Build for all of our targets. Building U3 and PortableApps installers using
the Express Editions of Visual C++ is problematic, since they require external
WinSxS assembly installations.
