This is a VERY PRELIMINARY version of tfshark. It's an attempt to jumpstart FileShark and its architecture. Right now it's mostly just a very stripped down version of tshark with all of the necessary build modifications (including now building filetap library since tfshark depends on it)
This code has helped me identify what I believe to be all of the necessary layers for a complete fileshark architecture. And those layers will slowly be added in time (patches always welcome!).
svn path=/trunk/; revision=54646
dissector for Novell's PKIS certificate extensions
from me
clean up the $Id$ tags
remove packet-pkis(-template).h
remove ASN.1 definitions that cause compiler warnings
(OID, SecurityLabelType2)
move the dissector to the clean ASN.1 dissectors
support CMake build
change the name to novell_pkis
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9597
svn path=/trunk/; revision=54508
supported by some versions of g++ even though the corresponding version
of gcc supports them. Other versions of g++, and clang, support them.
Check, before adding a -W option for C++, whether the compiler supports
it; that check must be done with -Werror, at least with g++, in order to
get a non-zero exit status from the compiler.
svn path=/trunk/; revision=54447
Given that Wireshark is moving to QT, the Wireshark changes required to
fix the features deprecated in Gtk 3.10 will not be done.
svn path=/trunk/; revision=54337
It should fix:
cc1plus: warning: command line option `-Wmissing-prototypes' is valid for Ada/C/ObjC but not for C++ [enabled by default]
(only g++ complains, clang is OK with -Wmissing-prototypes)
svn path=/trunk/; revision=54086
on what libwiretap thinks it is.
Update some comments to reflect the death of the hack used to include
(libwiretap) plugin support in programs not built with libwireshark.
svn path=/trunk/; revision=54015
./configure's options for gtk2 vs gtk3 vs qt.
Make it possible to not build the GNOME package (now both UIs' packages are
optional). I think Chris requested this a while ago.
If this works out it may make sense to control the rest of the options via
./configure .
svn path=/trunk/; revision=53607
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Code-Gen-Options.html#Code-Gen-Options
-ftrapv "generates traps for signed overflow on addition, subtraction,
multiplication operations." and -fwrapv "instructs the compiler to
assume that signed arithmetic overflow of addition, subtraction and
multiplication wraps around using twos-complement representation."
Those seem mutually-exclusive to me, and we probably want wrapping, not
traps, as there's probably a fair bit of code out there that explicitly
or implicitly assumes wrapping. (Actually, we really want to avoid
signed arithmetic for the cases that most matter, such as offsets and
lengths, but, unfortunately, we currently have API conventions that
allow negative values for lengths, either with -1 meaning "to the end"
or with negative values meaning "relative to the end".) In addition,
there seem to be some bugs complaining that -ftrapv doesn't always cause
traps on signed integer overflow.
We seem to be seeing crashes in Lemon on the Solaris buildbot subsequent
to adding -ftrapv; I don't know whether that's an overflow being
detected, a bug in the compiler, or something unrelated, especially
given that we're using Sun C, not GCC, on the Solaris buildbot.
However, we'll try removing -ftrapv, to see if it fixes the problem; the
MIT CSAIL paper in question wasn't really recommending all the GCC
options it mentioned (which, as noted, wouldn't make sense, as -ftrapv
and -fwrapv appear to be mutually-exclusive).
svn path=/trunk/; revision=53556
/usr/include/qt5/QtCore/qglobal.h:1079:4: error:
"You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC or -fPIE."
svn path=/trunk/; revision=53432
installing command-line developer tools with no SDKs but with a standard
UN*Xy /usr/include or of installing Full Frontal Xcode, if the user
didn't specify building against an SDK, check to see whether we *have*
any SDKs and, if not, don't set the deployment target.
svn path=/trunk/; revision=51501
configure Wireshark, so we don't, for example, do "make distcheck" with
no options, and thus default to GTK+ 3, on a system without GTK+ 3 where
Wireshark was configured with --with-gtk2. (This also means that if
we're configuring only with Qt, or with GTK+ *and* Qt, "make distcheck"
will check with those.)
svn path=/trunk/; revision=51456
the kernel" thing, and add the NetBSD and DragonFly BSD /proc links (if
they don't mount /proc, that doesn't work, but it doesn't get in the
way).
On Solaris, check for getexecname, just in case somebody tries to build
on an old Solaris that doesn't support it (that could well end up being
the least of their problems, but at least they won't ask us to diagnose
that one).
svn path=/trunk/; revision=51343
That way, if somebody specifies --with-gtk[23] and that version of GTK+
isn't found, we fail with an indication that the version of GTK+ they
asked for isn't there, and if no GUI toolkit was specified, and they
didn't explicitly say "don't build Wireshark", we look for GTK+ 3 and,
if it's not found, let the user know explicitly.
svn path=/trunk/; revision=51323
try it without -ldl (in case the OS doesn't have it - not a good idea,
as it complicates the build process for cross-platform tools that might
require it on other platforms, but "not a good idea" never stopped UN*X
vendors in the past) and, if that fails, try it with -ldl.
svn path=/trunk/; revision=51309
deployment target; if --disable-osx-deploy-target was specified, set it
to the OS version on which we're building - minor/dot-dot version and
all - as there's no guarantee that it'll work on *any* version earlier
than that.
svn path=/trunk/; revision=51060
anything other than OS X, fail; whatever it is you're trying to do won't
work (unless and until there exists a platform that fully supports
cross-development for OS X, *including* building against SDKs and
building with -mmacosx-version-min).
If you use neither on OS X, default to the OS major version on which
you're building. If you use --disable-osx-deploy-target, don't build
against an SDK and don't use -mmacosx-version-min.
svn path=/trunk/; revision=51057
packages, providing macros that we use in our configure script in case
somebody building from SVN doesn't happen to have the package installed
and thus doesn't happen to have those macros defined.
In the case of Qt, there *isn't* such a .m4 file, so we had to create
the macro. Move it to acinclude.m4, and rename it to
AC_WIRESHARK_QT_CHECK to indicate that it's our own check.
svn path=/trunk/; revision=50881
--disable-wireshark was not specified, build with GTK+ 3.
If any of --with-gtk2 or --with-qt are specified, and --with-gtk3 wasn't
specified, *don't* look for GTK+ 3 and don't build with it.
If *both* --with-gtk2 and --with-gtk3, fail.
svn path=/trunk/; revision=50872
@executable_path/../lib as well as /usr/local/lib, so we can use @rpath
in the install names in the executables and libraries in the application
bundle.
Have the osx-app.sh script tweak all references to libraries from
/usr/local/lib in all executables, libraries, and plugins in the app
bundle to use @rpath. (The "all" is important; it fixes the GTK+ crash
mentioned in the comment in osx-app.sh. The notion of doing all of them
came from the osx-app.sh script in a newer version of Inkscape.)
This renders the setting of DYLD_LIBRARY_PATH in the wrapper scripts in
the bundle unnecessary; remove it. (Ideally, we should try to get rid
of the wrapper scripts entirely, but that might have to wait for us to
switch to using Qt.)
svn path=/trunk/; revision=50560
tests using the compiler are done using the flags that
we'll be using when building.
Add a -mmacosx-version-min flag to CFLAGS/CPPFLAGS/LDFLAGS so that the
compiler tests use them. This may, or may not, obviate the need to set
MACOSX_DEPLOYMENT_TARGET in OSX_DEPLOY_TARGET.
svn path=/trunk/; revision=50426
when building for OS X; that causes the MACOSX_DEPLOYMENT_TARGET
environment variable to be set when building (so that, for example, we
don't use linker features available on the version on which we're
building but not on the minimum OS version for which we're building),
and causes the SDK for that version to be used (so that, for example, we
don't link with libraries with later version numbers than the ones
provided with the OS version for which we're building).
svn path=/trunk/; revision=50410
AC_WIRESHARK_COMPILER_FLAGS_CHECK, because it doesn't just affect CFLAGS
and it doesn't just affect the flags for GCC.
svn path=/trunk/; revision=50222
that it doesn't fail due to the C++ compiler not supporting -W options
that the C compiler does.
(We should fix that, too, by having separate checks for whether the C
and C++ compilers support particular options.)
svn path=/trunk/; revision=50215
C++ compiler (it might not be one on, for example, OS X, due to "cc"
being a C compiler, "CC" referring to "cc" due to the case-insensitivity
of the default OS X file system, and "CC" being one of the names checked
for in AC_PROG_CXX), so if we really need a C++ compiler, test it with a
program that a C compiler won't compile.
svn path=/trunk/; revision=50204
on a Mac, right? So of *COURSE* you want to use our shiny new frameworks
rather than those ugly old open-source multi-platform libraries, right?"
warnings.
svn path=/trunk/; revision=50200
bugs it points out that probably mean the code won't work on machines
that require alignment (e.g., SPARC machines), but we'll turn it on once
we fix them. (clang is fussier than GCC about this.)
svn path=/trunk/; revision=50187
an error, or not issue warnings, by default if you give them an unknown
-f flag. Instead, test that flag with all compilers, and use -Werror to
force it to error out.
As with C/C++ flags, so with C++-only flags.
svn path=/trunk/; revision=50178
machine, with both qt4 and qt5 development tools installed), moc and uic are the
qt5 versions, but the rest of the configuration process grabs qt4 headers and
link paths, leading to a lot of weird errors.
svn path=/trunk/; revision=50150
./configure now accepts:
--with-gtk2 : enabled by default; exclusive of --with-gtk3
--with-gtk3 : disabled by default; exclusive of --with-gtk2
--with-qt : disabled by default, can be specified with gtk
--enable-wireshark : controls whether *any* GUI is built
If Qt is enabled then a new program is created: "wireshark-qt". "wireshark"
remains the Gtk+ version.
svn path=/trunk/; revision=50147
Move DESKTOP_FILE_INSTALL into the group of programs used for packaging;
it's used when you install a source package. (It's not used to *build*
a source package, but....)
svn path=/trunk/; revision=49256
see whether it's Python 2 or not; if it's not, *then* look for Python 2.
That way, you can use Python on systems where python is Python 2 and
python2 doesn't exist.
Move the check for Python up after the check for Perl. (All the program
checks arguably belong together.)
AC_PATH_PROG() does AC_SUBST() for you; don't do it ourselves.
svn path=/trunk/; revision=49253
call PKG_PROG_PKG_CONFIG explicitly in configure.ac
AC_REQUIRE(PKG_PROG_PKG_CONFIG) may be expanded only under an if
statement that's not true and thus PKG_PROG_PKG_CONFIG will never be
called.
./configure --without-gnutls --with-libnl demonstrates the problem
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8634
svn path=/trunk/; revision=49215
Point users to https://code.google.com/p/pyreshark/ as an alternative to the
current Python support.
While we're in there, make it harder to enable Python: change it from
"--with-python" to "--with-broken-python" just to prevent people from enabling
unless they really mean it (are going to work on fixing it).
svn path=/trunk/; revision=49138
Wireshark compiles with -Wc++-compat and -Werror, at least on my machine
with llvm-gcc 4.2.1. Make that a standard -W flag, to keep code that
won't pass a C++ compiler from sneaking back in (except in the files
that can't currently be compiled with -Werror for various reasons).
svn path=/trunk/; revision=48535
Michael Mann