It looks like multi-configuration generators (notably MSBuild) need
Qt autogen properties set on the wireshark target as well as qtui. Do
so unconditionally in both cases. (We were doing so conditionally for
qtui before.)
Set CMAKE_AUTO{MOC,UIC,RCC} if we're running CMake 3.20.0 or 3.20.1 in
order to work around CMake issue 22085, otherwise set the AUTOMOC,
AUTOUIC, and AUTORCC properties for the qtui target. The latter is
preferred since it keeps us from running Qt's meta-object, user
interface, or resource compilers on code outside of ui/qt. Ping #17314.
C-ares has been mandatory since 451a241e50. Remove some checks that are
no longer needed.
Rename OPTIONAL_DLLS to THIRD_PARTY_DLLS and OPTIONAL_PDBS to
THIRD_PARTY_PDBS in CMakeLists.txt, which is more accurate.
When both qt (qt@6) and qt5 are installed via Homebrew, the build fails:
FAILED: ui/qt/CMakeFiles/qtui.dir/qtui_autogen/mocs_compilation.cpp.o
...
In file included from ui/qt/qtui_autogen/mocs_compilation.cpp:2:
In file included from ui/qt/qtui_autogen/EWIEGA46WW/moc_about_dialog.cpp:10:
In file included from ui/qt/qtui_autogen/EWIEGA46WW/../../../../../repos/wireshark/ui/qt/about_dialog.h:15:
In file included from /Users/pwu/repos/wireshark/ui/qt/models/astringlist_list_model.h:15:
In file included from /usr/local/opt/qt5/lib/QtCore.framework/Headers/QAbstractTableModel:1:
In file included from /usr/local/opt/qt5/lib/QtCore.framework/Headers/qabstractitemmodel.h:43:
In file included from /usr/local/include/QtCore/qvariant.h:43:
In file included from /usr/local/include/QtCore/qatomic.h:41:
/usr/local/include/QtCore/qglobal.h:667:26: error: no template named 'enable_if_t' in namespace 'std'; did you mean 'enable_if'?
typename = std::enable_if_t<std::is_arithmetic_v<T> && std::is_arithmetic_v<U> &&
~~~~~^
That qvariant.h header is from Qt 6 which is backwards incompatible:
/usr/local/include/QtCore -> ../Cellar/qt/6.0.2/include/QtCore
It appears that `<qt5 prefix>/include` must be explicitly included as
the default Qt5 include directories does not cover this:
$ find /usr/local -lname '*include/QtCore' -ls
... /usr/local/include/QtCore -> ../Cellar/qt/6.0.2/include/QtCore
$ find /usr/local -name qvariant.h -ls
... /usr/local/Cellar/qt@5/5.15.2/lib/QtCore.framework/Versions/5/Headers/qvariant.h
... /usr/local/Cellar/qt/6.0.2/lib/QtCore.framework/Versions/A/Headers/qvariant.h
$ find /usr/local -name QtCore -lname '*Headers' -ls
... /usr/local/Cellar/qt@5/5.15.2/include/QtCore -> ../lib/QtCore.framework/Headers
... /usr/local/Cellar/qt/6.0.2/include/QtCore -> ../lib/QtCore.framework/Headers
$ ls -la /usr/local/opt/qt5
... /usr/local/opt/qt5 -> ../Cellar/qt@5/5.15.2
As described at
https://medium.com/@alasher/colored-c-compiler-output-with-ninja-clang-gcc-10bfe7f2b949
both Clang and gcc generate colorized output when they detect a
terminal, but not for piped output, which is the case when using Ninja.
Add an ENABLE_COMPILER_COLOR_DIAGNOSTICS CMake option, and set it to
"ON" when we're using Ninja.
In the merge-req:ubuntu-gcc-ctest and merge-req:ubuntu-clang-other-tests
GitLab CI jobs, generate colorized HTML report artifacts using
ansi2html.
Calling cmake with -DENABLE_VLD=ON when building with Visual Studio,
results in debug configuration being linked to Visual Leak Detector.
By default, Visual Leak Detector outputs the leak summary to Visual
Studio debug window. When ENABLE_VLD is active, VLD is linked to all
wireshark libraries and executables.
Sometimes initializing the same field twice indicates a bug, so see
whether we can leave it enabled and suppress the warning in cases where
it's probably not a bug (too bad GCC didn't let you specify a default
initializer with, for example:
int foo[16] = {
[] = 17,
[12] = 34
};
which would mean we wouldn't have to suppress that warning in
ui/text_import.c).
Note also that not all compilers that can produce this warning call the
option "-Woverride-init".
As noted in be2b0fc810, we need to set CMAKE_AUTO* before searching for
Qt packages when using 3.20.0 and later. However, this fails if we're
using CMake 3.9.6 or earlier. Set CMAKE_AUTO* where needed depending on
our CMake version.
Ping #17314.
The distinction between the different kinds of capture utility
may not warrant a special subfolfer for each, and sometimes the
distinction is not be clear or some functions could stradle
multiple "categories" (like capture_ifinfo.[ch]).
Simplify by having only a generic 'capture' subfolder. The
separate CMake libraries are kept as a way to reuse object code
efficiently.
This policy says: "Since version 3.10, CMake processes regular and GENERATED
source files in AUTOMOC and AUTOUIC. In earlier CMake versions, only regular
source files were processed. GENERATED source files were ignored silently."
We are currently running AUTOMOC/RCC/UIC on too many files unnecessarily and
that should be improved. CMake 3.20 introduced some changes related with this
that broke the build (issue #17314) and need further investigation.
Meanwhile setting this policy to NEW shouldn't break anything and silences
some noisy CMake warnings.
Enable CMAKE_AUTOMOC, CMAKE_AUTOUIC, and CMAKE_AUTORCC before searching
for Qt packages. This is apparently required for CMake 3.20.0 and later.
Fixes#17314.
Modularized the parser backend slightly to have the needed hooks
Modified the timestamp format slightly to enable arbitrary postion for
second fractions
Added a regex based seeking parser for textfiles as frontend alternative
to text_import_scanner.l
Regex is using the GLib implementation
Supported frame-data formats are bin, hex, oct and base64
Regex based importing UI
Fixed Meory-leak in ImportTextDialog::exec()
A new tab was added to the text_import ui to accomodate the new fields
Hints are available and styled accordingly
The existing stuff doesn't appear to work (I tried it on 32-bit Ubuntu
18.04, and it did *not* add any flags to the compilation, as it appeared
not to conclude that they were necessary, even though they were).
Pull in the stuff from libpcap, which *does* appear to work. (it does
so in my 32-bit Ubuntu testing).
This should fix#17301.
While we're at it, fix cppcheck.sh so that it doesn't attempt to run
cppcheck on files that have been deleted.
This pull request includes:
* The "Follow DCCP stream" feature.
* Updated docbook documentation for the "Follow DCCP stream" feature.
* Test for the feature.
* Corresponding packet trace for the test.
Increase the minimum required version of Qt from 5.3 to 5.6. The various
Linux distribution versions that shipped with earlier Qt versions (RHEL
6, Fedora 23, openSUSE 13.2, Debian jessie, Ubuntu 16.04) have either
reached end of support or will do so soon.
The official Qt 5.6 releases for macOS require 10.8, so make that the
minimum macOS version.
Remove a bunch of no-longer-needed version checks.
The include_directories documentation at
https://cmake.org/cmake/help/latest/command/include_directories.html
says:
"Note: Prefer the target_include_directories() command to add include
directories to individual targets and optionally propagate/export them
to dependents."
Switch from include_directories to target_include_directories in a bunch
of places.
Add "SYSTEM" to the remaining external include_directories calls in
order to minimize our compiler warning blast radius.
Forcibly unset the cached version of CMAKE_VERBOSE_MAKEFILE if the
FORCE_CMAKE_NINJA_NON_VERBOSE environment variable is set, to make
*extra* sure that we don't do a verbose build.
Visual Studio's code analyzer lets you avoid analyzing external headers
using CAExcludePath. Add a note suggesting that we might want to do this
using the VS_USER_PROPS CMake property, but that for now we're using an
environment variable in the builder config.
Overriding the definition of the rpmbuild macro cmake_build on the
command line, so that it doesn't include the string "--verbose", should
prevent cmake --build from being run with --verbose, and thus prevent it
from running Ninja with the -v flag, and thus prevent a bunch of extra
noisy output from being produced for every build command, and thus
prevent the build log from hitting GitLab's 4MB limit.
Unlike piping the output of "ninja rpm-package" to sed, this means that
the exit status of "ninja rpm-package", rather than the exit status of
sed, is tested.
Filter out the -W and -f options from the output of "ninja rpm-package",
to try to cut down the verbosity.
Do that instead of passing --quiet to rpmbuild, so we get command
progress messages, just without the extra junk.
If the FORCE_CMAKE_NINJA_QUIET environment variable is set, have the
top-level CMakeLists.txt add the -q flag to the arguments to rpmbuild.
That appears to reduce the amount of output.
Set that environment varible in the rpm-fedora build.
Every supported distribution has at least the 3.3 branch of GnuTLS
(stable branch starting in April 2014). That branch was maintained
for bug-fixes until July 2018, so some distributions (e.g. RHEL7,
SUSE Enterprise 12) are still on it, keeping us from requiring 3.4 yet.
Also clarify a comment about when the Mac OS build of gnutls started
being compiled with pkcs11 support.
With RHEL/CentOS 6 EOL and already unsupported by Wireshark, there's no
reason to keep the minimum version of libgcrypt below 1.5.0 (which was
released 9.5 years ago). Version 1.6.0 is a big improvement in functionality,
but RHEL/CentOS 7 is stuck on 1.5.3 (As an aside, GCRYPT_VERSION_NUMBER
wasn't defined until 1.5.1, so this change will make us actually use the
libgcrypt AES-WRAP handling on 1.5.0)
New link type DLT_ETW is added for write and read Event Trace on Windows.
This change updates MBIM dissector to decode a MBIM message from
a DLT_ETW packet.
Enable PKCS #11 support in macOS builds with macos-setup.sh (already
supported on macOS via Homebrew and on all other OSes with GnuTLS 3.4
or greater) by installing p11-kit (and its dependency libtasn1) and
building nettle and GnuTLS against it.
Convert wiretap/ascend.y.in from Bison/YACC to Lemon and rename it to
wiretap/ascend_parser.lemon. Tighten up some of our scanning and
parsing. Make the indentation in it and related files consistent. Aside
from the recent IPv4 fragment offset changes, this produces identical
output to the 3.4 branch for the Ascend trace files I have here.
Remove the comment about supporting other commands. Another timeline
might have an Ascend that successfully pivoted to DSL or 15625B+1D
gigabit ISDN, but this one has neither.
This was our last/only Bison/YACC file, so remove Bison/YACC as a
development and packaging dependency and remove references to it from
the documentation.
It's possible to play opus payload with libopus (https://opus-codec.org/).
Closes#16882.
Helped-by: Pascal Quantin <pascal.quantin@gmail.com>
Signed-off-by: Lin Sun <lin.sun@zoom.us>
Signed-off-by: Yuanzhi Li <ryanlee@mail.ustc.edu.cn>
Gerald Combs