We can't install from DATAFILE_DIR on this platform, we
must use CMAKE_BINARY_DIR.
Do that and try to keep this thing intact.
Ping-Bug: 15301
Change-Id: I5c0b787f8b1a148dda52f26242ab681e3c3a0d44
Reviewed-on: https://code.wireshark.org/review/30879
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
CMake requires zlib to be added to the exports via epan and wiretap
targets.
Ping-Bug: 15301
Change-Id: I5cfe746e67c195eb83b1d159a2cc2a645c8c47ea
Reviewed-on: https://code.wireshark.org/review/30793
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Upcoming changes need GnuTLS >= 3.0.2. Require GnuTLS 3.2 (or newer) for
licensing reasons. The Debian control file still mentions 3.2.14 because
older packages linked with a GMP library that was not GPLv2+ compatible.
RHEL6 only has 2.12.23, but is already unsupported anyway.
Change-Id: I024b2a734ebb16b73a624bb2435c254e963d8b7d
Reviewed-on: https://code.wireshark.org/review/30832
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Currently our Windows code looks for data files in the same
folder as the binary executable (presumably to make the
application relocatable, although it should be possible
to improve this with relative paths?).
Ping-Bug: 15301
Change-Id: I0fef4e87dc9d1d8edef81dd11755761fddd0fd12
Reviewed-on: https://code.wireshark.org/review/30819
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
libwireshark and libwiretap have their INTERFACE link dependencies
changed to the required set.
libwsutil keeps a default public visibility. Further work may
show some unneeded link requirements.
The executable dependencies are adjusted accordingly.
Change-Id: I3a534f72403819cac136ae47a3d80acee76e0fb3
Reviewed-on: https://code.wireshark.org/review/30815
Reviewed-by: João Valverde <j@v6e.pt>
The installation step cannot depend on CMAKE_CFG_INTDIR.
This step is executed in a cmake script without the build
tool so variables like $(Configuration) of Visual Studio
don't get substituted, breaking the installation.
Ping-Bug: 15301
Change-Id: Idc0c48b6dc440ad1d9b2d6a2824cc89190997b60
Reviewed-on: https://code.wireshark.org/review/30784
Reviewed-by: João Valverde <j@v6e.pt>
Install headers to support plugins development on Windows.
Change-Id: I3161bd2f730edf62ab44fee6ce4fedbb9aee0d31
Reviewed-on: https://code.wireshark.org/review/30776
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
AppleClang 9.1.0.9020039 is complaining about a "missing initializer" in
dumpcap.c. Rather than doing ugly things like one of the following:
struct s x;
memset(&x, 0, sizeof(x));
struct s y = {.field=0};
just disable the warning (enabled via -Wextra) on broken compilers. The
minimum versions were determined using https://gcc.godbolt.org/
The special "universal zero initializer { 0 }" exception is explicitly
documented in the GCC manual (as shipped with GCC 8.2.1). Clang 6 does
not document it, but r314499 (as included with Clang 6) does implement
it and adds tests for it. (Xcode 10.0 seems based on Clang 6.0.1.)
Change-Id: I8e48d8c424a512ca36ef8c4f832ce81b3675232c
Reviewed-on: https://code.wireshark.org/review/30684
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
JSON-GLib was added in v2.9.0rc0-201-g511c2e166a, but is no longer
necessary since we have a home-grown JSON dumper (wsutil/json_dumper.h).
Remove the remaining traces and additionally remove GObject from
FindGLIB2.cmake since it was only added for JSON-GLib.
Change-Id: If9dfd2c60cec130f98109d100bdb6618bde06ba0
Reviewed-on: https://code.wireshark.org/review/30733
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
cmake_minimum_required() MUST be called even before project(), otherwise
some policies will not be correctly set. On the macOS build on Travis
for example, CMP0025 was accidentally set to "OLD" which resulted in
CMAKE_C_COMPILER_ID being reported as "Clang" instead of "AppleClang".
Change-Id: I20065e621628cde24946edb519d719f527936d87
Reviewed-on: https://code.wireshark.org/review/30685
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
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>
João Valverde