Python 3 is widely available. All major Linux distributions support it.
RHEL is covered via EPEL (which is already required for cmake3). Drop
support for Python 2 in order to reduce maintenance costs. The main
motivation is being able to simplify the tests.
CMake is updated to search for Python >= 3.4 and will fail if
unavailable (generating dissectors.c requires Python, so it is quite an
important piece to have).
The documentation is updated to reflect the Python 3.7 paths used by
Chocolatey. Tested the git-review installation instructions in Windows 7
x64 without a previous Chocolatey installation.
macOS brew now installs Python 3 (its dependencies are already installed
by python@2 for libxml2). The macOS (non-brew variant) is updated to use
the official 64-bit installer to install Python 3.
Change-Id: I80b1e36957f338e0dad1bfcc173b6418682cddba
Reviewed-on: https://code.wireshark.org/review/30192
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
check_function_exists (as used by FindZLIB.cmake) seems to fail with the
-pie option as well, do not try to enable it when building for oss-fuzz.
Change-Id: I7d7e0fce1972483a14ac0a91a9f144f22c5ae8a0
Fixes: v2.9.0rc0-2349-g895ad30b5a ("CMake: Fix -pie linker test")
Reviewed-on: https://code.wireshark.org/review/30431
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Fix wrong argument order on invocation of check_c_linker_flag().
Change-Id: If4b016b428983580f3fbd00433bee904db97b2a3
Reviewed-on: https://code.wireshark.org/review/30397
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
The current fuzzshark target built by CMake is not usable for fuzzing.
Address this by adding a new ENABLE_FUZZER option that enables mandatory
instrumentation and libFuzzer linking options for the fuzzshark binary.
Create more CMake targets for specific fuzzing targets such as
fuzzshark_ip and fuzzshark_ip_proto-udp. These targets are not built by
default, either build individual targets or use the all-fuzzers target.
Now these binaries are not specific to oss-fuzz, so move them to a new
directory (perhaps the corpora can be added here in the future).
oss-fuzz build.sh is simplified and reuses the CMake targets.
When OSS_FUZZ is set, it will force static linking with external
libraries and limit parallel linker jobs (maybe not necessary for
Google's oss-fuzz builders, but my 8G/6c VM ran out of memory).
Change-Id: If3ba8f60ea1f5c3bd2131223050a81f9acbce05d
Reviewed-on: https://code.wireshark.org/review/30228
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
WS_LINK_FLAGS also apply to libraries, but -pie has no effect on them.
Change-Id: I9c7fde228c5faf20edf0ad45692577070b24a280
Reviewed-on: https://code.wireshark.org/review/30239
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Use a single template file for most of our program resources. Encode
our resource files as UTF-8. Add resources to extcap/*.exe.
Replace a regex with concatenation.
Change-Id: I0ed49086618127ca4fdef69272f849d8f16e4dab
Reviewed-on: https://code.wireshark.org/review/30088
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
We already do that for the macOS-specific system libraries; do it for
the Windows-specific system libraries as well.
Change-Id: I4646cbf5043406a9b6be70307b51df2fbe0329dd
Reviewed-on: https://code.wireshark.org/review/30066
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Doing so for command-line programs means that the argument list doesn't
ever get converted to the local code page; converting to the local code
page can mangle file names that *can't* be converted to the local code
page.
Furthermore, code that uses setargv.obj rather than wsetargv.obj has
issues in some versions of Windows 10; see bug 15151.
That means that converting the argument list to UTF-8 is a bit simpler -
we don't need to call GetCommandLineW() or CommandLineToArgvW(), we just
loop over the UTF-16LE argument strings in argv[].
While we're at it, note in Wireshark's main() why we discard argv on
Windows (Qt does the same "convert-to-the-local-code-page" stuff); that
means we *do* need to call GetCommandLineW() and CommandLineToArgvW() in
main() (i.e., we duplicate what Qt's WinMain() does, but converting to
UTF-8 rather than to the local code page).
Change-Id: I35b57c1b658fb3e9b0c685097afe324e9fe98649
Ping-Bug: 15151
Reviewed-on: https://code.wireshark.org/review/30051
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This reverts commit 84447550ef.
Reason for revert: CMake's documentation for the flags variables is
close to content-free, giving no indication what the link flags used
in the link will be, given a combination of various CMAKE.*LINKER_FLAGS
variables and LINK_FLAGS properties. That makes it extremely difficult
to determine why this change happens to cause some executables to
be linked with "/INCREMENTAL" and others to be linked with
"/INCREMENTAL:YES", even though we add "/INCREMENTAL:NO" to
WS_LINK_FLAGS and add WS_LINK_FLAGS to CMAKE_EXE_LINKER_FLAGS - or
why *not* setting CMAKE_EXE_LINKER_FLAGS and instead using LINK_FLAGS
*doesn't* cause that to happen.
Maybe it's an issue of CMAKE_EXE_LINKER_FLAGS vs.
CMAKE_EXE_LINKER_FLAGS_<CONFIG>, but the documentation doesn't
clearly indicate whether, for example, the link flags for a particular
executable target are a combination of CMAKE_EXE_LINKER_FLAGS, the
CMAKE_EXE_LINKER_FLAGS_<CONFIG> flag for the configuration of this
build, and the LINK_FLAGS property of the target, if any. That's
the most *obvious* behavior to implement, but if that's the behavior
that's implemented, I'm not sure why the change being reverted had the
effect it did.
Change-Id: I6a73fe88be65378d506a89460f7362076233f319
Reviewed-on: https://code.wireshark.org/review/30023
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Just set CMAKE_EXE_LINKER_FLAGS to include ${WS_LINK_FLAGS}, and also
set it to include setargv.obj on Windows.
This is a bit simpler.
Change-Id: Idf9c632d9d3bff1ec6e70396641319155e08aa4f
Reviewed-on: https://code.wireshark.org/review/30004
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Libraries shouldn't be linked with it.
See if this fixes the weird problems I'm having with mergecap -
including, apparently, the mergecap from the buildbots - when run with
wildcard arguments, terminating before it gets to main() (making it hard
to try to debug bug 15151).
Change-Id: Ie793b0ea8157186a121106636ac8b782457c09f5
Reviewed-on: https://code.wireshark.org/review/29985
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add an sdjournal extcap, which reads journal entries using the
sd-journal API and dumps them as journal Export Format records.
Change-Id: I17ccfa88ab5d053c16c869cd26e580d84022502e
Reviewed-on: https://code.wireshark.org/review/29479
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Installing and enabling ccache makes testing RPM builds (which always do a
complete build) much less painful.
Change-Id: Ie9ab1794614701cdbe261089f81398c2b7d1f027
Reviewed-on: https://code.wireshark.org/review/29812
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Don't require the RPM to include maxminddb if we couldn't find it. Treat it
like the other optional packages: enable it in the RPM iff we found it.
IOW if cmake ran and will build Wireshark [without maxminddb] you'll also be
able to build an RPM [without maxminddb].
Change-Id: I012b75ae44e9289275b68db2eb804fc45bb0d330
Reviewed-on: https://code.wireshark.org/review/29807
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
Its handling of warnings, and of warnings-treated-as-errors, is horribly
broken; once you've asked for a warning, and have specified -Werror,
there appears to be nothing whatsoever that you can do to keep that
warning from being an error *everywhere* in the code.
Prior to change Ib591a1d6beaa13337d927a446b4d8d5e687ff610, the tests for
warnings were all failing on the macOS buildbot, so *no* warnings were
being requested.
With this change, a warning won't be reported as an error, but at least
it'll be reported.
(We should probably switch to using Clang on the macOS buildbot at some
point; I don't know whether the version of Clang currently on the
buildbot is safe to use, but if we ever run a newer version of Xcode,
which doesn't come with llvm-gcc - which may involve running a newer
version of macOS on the buildbot as well - it's presumably safe, given
that it's the only compiler Apple shipped.)
Change-Id: I677967cb87b91f68f08de546e59abff1dbd6788b
Reviewed-on: https://code.wireshark.org/review/29623
Reviewed-by: Guy Harris <guy@alum.mit.edu>
If you specify -Werror and -Wshorten-64-to-32, there does not appear to
be any way to get llvm-gcc *NOT* to treat those warnings as errors - not
with pragmas, and not even with -Wno-error=shorten-64-to-32.
Change-Id: Ia82df3f548085cca8d187c4b43c02060b87f0542
Reviewed-on: https://code.wireshark.org/review/29620
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Replace a tab in an arguments string with a space while we're at it.
Change-Id: Iee6ce920fbd7a883fb23bc798abb7f965e3757e6
Reviewed-on: https://code.wireshark.org/review/29619
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Ninja, at least, complains about tabs.
Change-Id: I65c3458dadc7096773084864d5e3970d1d9d580d
Reviewed-on: https://code.wireshark.org/review/29618
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It appears that -Werror overrides them, at least with llvm-gcc; I guess
the options are evaluated in order.
Change-Id: I0fd9e544a8e191a8950e17e97513912034763645
Reviewed-on: https://code.wireshark.org/review/29615
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Was Apple trying to release a game for Mac OS X, somewhat resembling
Whack-A-Mole, when they went into the lab and had Igor help them stitch
together the GCC front end and the LLVM back end?
Change-Id: If08392c3d244a83f50f62b4d7c878ae9a274ec4b
Reviewed-on: https://code.wireshark.org/review/29614
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Always use -Werror if it's supported, even with Apple's llvm-gcc, and
only use -Wno-error= with llvm-gcc. Use -Wno-error= with all the errors
we get in the buildbot.
Change-Id: I6797f064d2d354f979e24fcb04f592e9313af721
Reviewed-on: https://code.wireshark.org/review/29612
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Apple's llvm-gcc appears not to support suppressing warnings with
pragmas, so, if we're building on a Mac (we check for APPLE), and we're
not using Clang, we don't turn on -Werror, because we rely on those
pragmas to suppress otherwise-unremovable warnings in order to build
warning-free.
Change-Id: I43bd1ab42918c6ba22643b4a2d4cc3618c25434b
Reviewed-on: https://code.wireshark.org/review/29609
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The original reason for having a WARN_FLAGS set of variables has
been lost.
Change-Id: I3eae3cf9d0bad5f3895f6fee59c2c64183c8f244
Reviewed-on: https://code.wireshark.org/review/29526
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
- It cannot support IPv6.
- Non-standard use (specifically recommended against in the RFCs)
of the IPv4 fragment ID field.
- Has a narrow and non-obvious use case, IMO.
- It is not supported in the Qt GUI.
- Significant maintenance burden for an obscure feature.
Change-Id: Icaf429269dc42f78c38b8d20001508132499faf8
Reviewed-on: https://code.wireshark.org/review/29239
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
These warnings should already be suppressed for Qt with -isystem.
Change-Id: I9b5640f1b6da9fa8039deb2810eda3d878779c38
Reviewed-on: https://code.wireshark.org/review/29500
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
Remove all the duplicate code. Each test result is cached so it
needs an unique variable to store the result.
Change-Id: Ib591a1d6beaa13337d927a446b4d8d5e687ff610
Reviewed-on: https://code.wireshark.org/review/29485
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
doc/README.wslua reports support for 5.1 and 5.2 only. Even RHEL6 ships
with Lua 5.1, so it makes not sense to maintain support for Lua 5.0.
Change-Id: I34a8084c7fba19d631b90ce5d5a28198be6a7850
Reviewed-on: https://code.wireshark.org/review/29448
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Update docbook/wsug_src/*.txt using tools/update-tools-help.py. This
removes a lot of unwanted behavior that came with updating via a CMake
target.
Change-Id: I0a24f425e9673ef7bd074210d7047654c6755e79
Reviewed-on: https://code.wireshark.org/review/29416
Reviewed-by: Gerald Combs <gerald@wireshark.org>
The Resources directory was removed a while back. Since CMake 3.12, the
copy_directory command will fail when the source directory is missing.
Reported by anta_tw in the #wireshark IRC channel at Freenode.
Change-Id: I4de087dd2833e79a806c8a0c9a28024848e1e03f
Fixes: v2.1.0rc0-2347-g4aa049019a ("OS X: Remove GTK+ packaging.")
Reviewed-on: https://code.wireshark.org/review/29304
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
A CMake config-file package provides support for downstreams using
CMake and Wireshark libraries to easily configure the libwireshark
dependency with:
find_package(Wireshark CONFIG [REQUIRED])
target_link_libraries(foo epan)
The FindWireshark.cmake file is no longer needed.
See cmake-package(7) for more details on CMake's package system.
Change-Id: Ie8af1d44417a99dd08d37959f7b2ffca88572ec2
Reviewed-on: https://code.wireshark.org/review/29208
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
This is one of the CMake standard paths on Unix and avoids polluting the
$libdir/wireshark folder.
Change-Id: I6e5fd81e95b52e585e92306aca18dfb2426668ca
Reviewed-on: https://code.wireshark.org/review/29255
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
Change the plugin compatibility check to make it more convenient to
define and check the major.minor Wireshark version.
Change-Id: I2a6d2a746682c29504311cce5c457e0a852c3daf
Reviewed-on: https://code.wireshark.org/review/29224
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
Remove what appears to be a debug message from CMake.
Change-Id: If6d12ca07d3c3b5f012a7e7ee530f7db18c813e5
Reviewed-on: https://code.wireshark.org/review/29215
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Verified that the tests failed without the fixes for the linked bugs.
The tests have full statement coverage(*1) for check_follow_fragments
and follow_tcp_tap_listener. For details and Scapy script, see:
https://git.lekensteyn.nl/peter/wireshark-notes/commit/crafted-pkt/badsegments.py?id=4ecf9d858b49e76d8a9c29df01ce1bd523ae6704
(*1) except for `if (data_length <= data_offset) { data_length = 0; }`
Change-Id: I625536df375272cf6c9116231194c39df1217fae
Ping-Bug: 13700
Ping-Bug: 14944
Reviewed-on: https://code.wireshark.org/review/28618
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>