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] CMake status

From: Graham Bloice <graham.bloice@xxxxxxxxxxxxx>
Date: Tue, 6 Jan 2015 11:32:35 +0000


On 6 January 2015 at 11:26, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:


On 5 January 2015 at 23:54, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Jan 5, 2015, at 3:11 PM, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:

> FWIW my current Windows CMake list of tasks to do (in no particular order):
>       • Add zlib to build.

What remains to be done there?  The buildbot Win32 and Win64 builds both appear to be picking up zlib.

Or do you mean "build zlib as part of the build process"?

Yes build zlib as part of the build process.  Currently CMake will pick up an already compiled zlib (from nmake), but due to VC runtime compatibility issues (which hopefully may be going away) we need to build zlib with the same tooolchain as the rest of the build.


>       • Fix compile warnings.

Are there compile warnings we're getting from the CMake build that we're not getting from the nmake build?

Yes, See the end of the last successful buildbot Cmake build (it appears to be broken again) http://buildbot.wireshark.org/trunk/builders/Windows%207%20x64/builds/11848/steps/shell_2/logs/stdio

One warning about dup messages in the Italian translation and two warnings about dup definitions when compiling packet-kerberos.  These may be artefacts of the CMake build rather than actual warnings to be fixed in code.

The x64 Cmake build also picked up another one that is likely to be genuine:

C:/buildbot/wireshark/wireshark-master-64/win7x64/build/cmbuild/epan/uat_load.c(1351): warning C4267: '+=' : conversion from 'size_t' to 'guint', possible loss of data
 


>       • Fix CMake warnings.
>       • Fix WinPcap version number for compile.

That information isn't available from WinPcap itself.

But it's not available from libpcap itself, either, and we don't report it with libpcap; should we just stop reporting it with WinPcap as well?

(The version of *pcap with which we're *running* is available with newer versions of libpcap and WinPcap, because I added pcap_lib_version() to libpcap a while ago.)


The nmake build uses the (hard-coded) value from config.nmake and passes it in as a compiler definition.  It seems that it's also used by NSIS installer.  Hard-coding isn't great but I'm not sure what we can do here.

--
Graham Bloice



--
Graham Bloice