ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Problem compiling Wireshark 1.6.1

From: Graham Bloice <graham.bloice@xxxxxxxxxxxxx>
Date: Wed, 24 Aug 2011 09:39:31 +0100
On 23/08/2011 21:55, Chris Maynard wrote:
> Andreas <AndreasSander1@...> writes:
>
>> Am 23.08.2011 22:30, schrieb Chris Maynard:
>>> Andreas<AndreasSander1@...>  writes:
>>>
>>>> Yes, I tried. I need only libwireshark. That's why I reduced the make
>>>> targets to build. But, alas, I get exactly the same result, when I
>>>> "nmake all".
>>> Can you verify that MSVC_VARIANT is set correctly in config.nmake?
>> MSVC_VARIANT=MSVC2008   matches with my compiler.
> Just to be sure, you might try another:
> nmake distclean
> nmake all
> [fail]
> nmake all (again)
>
> If you still don't progress any further and can live w/out zlib support
> temporarily just so you can get on with the rest of your work, you could try
> commenting out ZLIB_DIR in config.nmake.  Also, you may want to recheck that you
> followed all steps in the developer's guide:
> http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html
>
> One other thing that *might* be a problem (whether it's related or not, I don't
> know) is that you have python 2.7 installed and the notes in config.nmake
> indicate the following:
>
>         # NOTE: The Python library must have been compiled with the same
>         # compiler (MSVC_VARIANT) as Wireshark. Known python.org Python
>         # CRT versions:
>         #
>         # Python version    CRT (32-bit)    CRT (64-bit)
>         # 2.4.4             7.1             ?
>         # 2.6.1             9.0             ?
>         # 2.6.2                             9.0
>
> ... so this tells me you should probably be using 2.6.1 or 2.6.2.
>
Using the corresponding versions of Python and MSVC is only important when you
are including the python interpreter support within Wireshark, i.e.
PYTHON_EMBED is defined.

The reason for this, along with the reason for rebuilding zlib rather than
using the pre-built DLL is that a process shouldn't use components (the exe
and any DLL's or libraries) that use a different CRT as memory allocations are
not transportable across CRT's.

To ensure consistency we rebuild zlib as it isn't too hard to do, but is far
to hard for the python interpreter.

When just using Python as a build tool the version doesn't matter, although
there was an issue reported yesterday when using Python 3.2.

-- 
Regards,

Graham Bloice