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>
Remove -DBUILD_WINDOWS and sections of code that we no longer use.
Bug: 14715
Change-Id: Iae1a950e2f52f4ce45fcf0ae5dea06c1172c3a28
Reviewed-on: https://code.wireshark.org/review/28466
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Gerald Combs