Bug: 10791
Change-Id: I58c35c757039e69111a39100f5ccb306e098d591
Reviewed-on: https://code.wireshark.org/review/10519
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Reviewed-by: Michael Mann <mmann78@netscape.net>
On many systems, Qt5 requires that code compiled against it must compile
with -fPIC. The preferred place to determine whether this is necessary
is at configure time. This change adds the auto-tool code to make that
happen and removes the hack put in place as an interim solution.
Bug: 11230
Change-Id: I6e583c67bb67d168a30c0af05a8cd0a070522ba0
Reviewed-on: https://code.wireshark.org/review/10281
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
That's one of the mechanisms the autotools documentation suggests using
to handle generated header files.
Using it means that "make dist" will no longer try to build those files
(they're not part of the distribution - and they can't be, as the files
would be different for Qt 4 and Qt 5, and need to be generated by the
uic from the same version of Qt as the one against which Wireshark is
being built).
This means we don't need to try to find uic, moc, or rcc if we're not
building with Qt, so don't do so.
Change-Id: Id2aadb8289598b82e14e4ed402ff8cdc15fdef74
Reviewed-on: https://code.wireshark.org/review/9583
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
For example, Qt 4's uic produces .h files that don't compile with Qt 5,
as they use header #include paths that work with Qt 4's headers but not
Qt 5's headers.
Change-Id: I50c7bd15fca05475180a933a6c77955dc686c0c5
Reviewed-on: https://code.wireshark.org/review/9567
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
If you don't specify --with-qt or --without-qt, we build with Qt iff we
find it; we don't fail if we don't find it.
If you specify --with-qt, we build with Qt if we find it and fail if we
don't find it.
If you specify --without-qt, we don't look for Qt and don't build with
it.
This is all independent of --with-gtk2 or --with-gtk3.
Change-Id: I508d3281192bda9168fc46aba6011687c83ef818
Reviewed-on: https://code.wireshark.org/review/8861
Reviewed-by: Guy Harris <guy@alum.mit.edu>
First, search for packages with the version number without the period (bug
11219).
Second, don't look for Lua 5.3 because we don't work with it. If what we find
(without pkg-config's help) is Lua 5.3, disable Lua support (bug 10881).
Cmake support by Peter Wu (originally Ie73e5b53640f10432881a9671c0a605f7f027ed8):
Note the check for "lua<=5.2.99" instead of "lua<5.3" since cmake does not
support the latter syntax. Tested with lua5.2, lua5.1 and lua (5.3) installed.
Bug: 11219
Ping-Bug: 10881
Change-Id: I382d07ca00eafc6111cd4e9faa2b66f6b8f95b6e
Reviewed-on: https://code.wireshark.org/review/8783
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
The TOOL variant will automatically search for host prefixed scripts
(e.g. armv7a-unknown-linux-gnueabi-pcap-config) before falling back
to the default (i.e. pcap-config). This makes cross-compiling a bit
simpler.
Change-Id: Ia450839693b5550f798634a7e8b82c2a661b088c
Reviewed-on: https://code.wireshark.org/review/8481
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Without a major version number, it behaves as before, picking whatever
version it finds, and preferring Qt 5 to Qt 4. With a major version
number, it looks only for the version in question.
Bug: 10793
Change-Id: Idf6c2c61e84bb87f7b601d8f09c33f31b67bf46d
Reviewed-on: https://code.wireshark.org/review/8052
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Otherwise, just because a flag is appropriate for $CC, that doesn't
necessarily mean it's appropriate for $CFLAGS_FOR_BUILD.
(We don't use CFLAGS_FOR_BUILD for many things, so it's probably not
worth making a lot of effort to throw all the warning flags into it if
we're cross-compiling; we *do* throw them in for native compilation,
which is what most developers use and test with, so that should be
sufficient to let the warnings catch problems with the build tools we're
building.)
Change-Id: Iad9d611b4687e9e154f9871f741f3c8f3b307c88
Reviewed-on: https://code.wireshark.org/review/8026
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It can be set if either 1) this is Windows (where we're assumed to be
using WinPcap, which includes calls to set the buffer size) or 2) we
have pcap_create() (in which case we also have pcap_set_buffer_size(),
at least in a normal libpcap release).
Use that rather than testing "defined(_WIN32) ||
defined(HAVE_PCAP_CREATE)"; that makes it a bit more obvious what's
being tested.
Change-Id: Id9f8455019d19206b04dd6820a748cb97ae5ad12
Reviewed-on: https://code.wireshark.org/review/7816
Reviewed-by: Guy Harris <guy@alum.mit.edu>
configure if we can't find any name resolver (autotools only).
This puts back the gethostbyname()/gethostbyname2() code removed in
I3348179626e97daaddfbc89e3ed21e39915e3de4 and
If59ce8a038776eadd6cd1794ed0e2dad8bf8a22c but as a last-resort option (only
if we don't have a better or more modern name resolver).
As suggested/requested by Guy in https://code.wireshark.org/review/#/c/7423/
Change-Id: I706dbbd65135f47c67d3d8d88a61ad7273914c47
Reviewed-on: https://code.wireshark.org/review/7447
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
AC_CHECK_FUNC() doesn't define HAVE_XXX but AC_CHECK_FUNCS() does. And
AC_CHECK_LIBS() certainly doesn't define HAVE_<function>.
Also remove some ancient comments.
Change-Id: I49d701bb96d3bd3c55c4beb99d532e397ec554ad
Reviewed-on: https://code.wireshark.org/review/7400
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
They've been deprecated for a very long time. Replace them with
getaddrinfo. Note that we might not want to do synchronous name
resolution at all.
Add HAVE_GETADDRINFO to the KfW win-mac.h collision list.
Change-Id: If59ce8a038776eadd6cd1794ed0e2dad8bf8a22c
Reviewed-on: https://code.wireshark.org/review/6958
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
First, it appears some packagers actually ship a pkg-config file for Lua.
Try to use it. (Unfortunately the package name varies so we have to try
several package names.)
If that fails, try to find Lua directly, accounting for the various naming
conventions we've seen.
Bug: 10475
Bug: 10572
Change-Id: I82e789c466a488dc12431cdd90c49b4c1052414a
Reviewed-on: https://code.wireshark.org/review/6756
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
WinPcap 3.0 introduced pcap_open(); it also introduced
pcap_findalldevs_ex() and pcap_createsrcstr(). If you're going to put
pcap_open() in libpcap, there's not much point to doing so but not also
putting pcap_findalldevs_ex() and pcap_createsrcstr() there.
(And, in the future, there'll be support for remote capturing with
pcap_create() and pcap_activate(), with no need for pcap_createsrcstr(),
and a replacement for pcap_findalldevs() and pcap_findalldevs_ex(),
which we'll also check for.)
So there's no need to check for pcap_findalldevs_ex() or
pcap_createsrcstr().
Change-Id: I9323aad20136684d05d1e909326792a2f1408887
Reviewed-on: https://code.wireshark.org/review/6311
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add Telephony menu items for VoIP Calls and SIP Flows. Put VoIP Calls at
the top, since that seems to be the primary item.
Add configure-time checks for QtMultimediaWidgets in anticipation of
adding a VoIP playback dialog.
Add an icon for the playback button. (Yes, I've been avoiding
GNOME-level gratuitous icons so far but this is one of the rare
occiasions where it makes sense.)
Add a help link define for the VoIP calls dialog.
Change-Id: I5d0799685c598ad9af76fe9667f8ea7d14b66050
Reviewed-on: https://code.wireshark.org/review/5674
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
If we have pcap_set_tstamp_precision(), use it to request nanosecond
time stamp resolution *if* we're writing a pcap-ng file; any code that
reads those files and can't handle nanosecond time stamp resolution is
broken and needs to be fixed.
If we're writing a pcap file, don't ask for nanosecond resolution time
stamps, as that requires a different magic number for pcap files, and
not all code that reads pcap files can handle that. (Unlike pcap-ng,
where the ability to have non-microsecond time stamp resolution was
present from Day One, it's a relatively recent addition to pcap.) We
could add a command-line option/GUI option for that, like the option
recent versions of tcpdump have, if it matters.
Change-Id: I8fa464eb929feecb9a70be70712502c9f0cc5270
Reviewed-on: https://code.wireshark.org/review/4355
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The line "Massachusetts Institute of Technology" now appears
across two lines in the header file.
Change-Id: I618b520d6c15f51180b47d93c75e29a6f43b868b
Reviewed-on: https://code.wireshark.org/review/3790
Reviewed-by: Evan Huus <eapache@gmail.com>
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
That's what we do with nmake and CMake; this makes it uniform, so it's
easier to compare compiler commands.
Change-Id: Ice2c4bd796e921fa3089e8a45a32ad14d9b0e0a4
Reviewed-on: https://code.wireshark.org/review/3387
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Not all AC_WIRESHARK_LDFLAGS_CHECK flags are -Wl,{option} flags, so
don't check for that first. If we want to check for specific compilers
and linkers, we should do that, not for -Wl,{option} support.
Change-Id: Ib9581d4a1573a1ffa2493ce08e6d5845d2601352
Reviewed-on: https://code.wireshark.org/review/2755
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This caues a bunch of bogus "no"s to be printed when testing for
various compiler options when the compiler isn't GCC-like enough to
accept GCC-style -W, -f, and -m flags.
Change-Id: I16cf45729c61d166644cbddccfbaeb9b7770b045
Reviewed-on: https://code.wireshark.org/review/2365
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Adding -Qunused-arguments to CXXFLAGS causes the checks for -f and -m
flags not to fail with clang++, causing the configure script to warn
about -f flags supported by clang but not clang++ indicating that the
compilers are a mismatched pair.
The checks we do for flags should eliminate "unused" -f/-m flags,
suppressing the warnings that way.
Change-Id: I749d6f499a3d34300518cc0ba539f355377359af
Reviewed-on: https://code.wireshark.org/review/2362
Reviewed-by: Guy Harris <guy@alum.mit.edu>
As with -f flags, some compilers need -Werror to force the compiler to
fail when passed an unknown -m flag.
Also, if it's not a -W or -f or -m flag, don't forget to add it to
CFLAGS and/or CXXFLAGS.
And propagate a comment to the C++ flag testing.
Change-Id: I53e0e59b34b10b9477c60ddd4f2e047b3b8be77f
Reviewed-on: https://code.wireshark.org/review/2361
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Bereft of life, it rests in peace.
Change-Id: I8b9bc8c6cef0635d5526aa6b389aa33bc41fbc66
Reviewed-on: https://code.wireshark.org/review/2284
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We test whether a given compiler supports a given -W flag, so we don't
need to separate them and check them only for particular compilers.
To make that even clearer, rename the --enable option from
--enable-extra-gcc-checks to --enable-extra-compiler-checks, and
document it as just "do additional -W checks", and rename the
WIRESHARK_EXTRA_GCC_ CMake variables to WIRESHARK_EXTRA_COMPILER_.
Sync up the lists of warning flags in CMake with the lists in autoconf.
Uncomment -Wdocumentation while we're at it. If it doesn't work *at
all*, comment it out until it's fixed, or, better yet, fix it; if it
still produces warnings, we just leave it among the "extra" flags.
Change-Id: I4042affdade612e4025e2881d08f1ca69d759626
Reviewed-on: https://code.wireshark.org/review/1226
Reviewed-by: Guy Harris <guy@alum.mit.edu>
At least one person didn't realize that it meant that you have to
specify --with-ssl when configuring, so try saying that a bit more
explicitly.
Change-Id: If15a9cfaeaf7d4aca2c570602fc09ff3ae489d35
Reviewed-on: https://code.wireshark.org/review/575
Reviewed-by: Guy Harris <guy@alum.mit.edu>
build 5658) (LLVM build 2336.11.00)" likes -Wmissing-prototypes but not
-Wmissing-declarations and G++ 4.8.2 likes -Wmissing-declarations but
not -Wmissing-prototypes, so check whether *either* of them requires
-Werror in order to be detected as NSFC++.
Fix a copy-and-pasteo while we're at it.
Don't treat a different willingness to accept
-Wmissing-{prototypes,declarations} as an indication that you have
mismatched C and C++ compilers.
svn path=/trunk/; revision=54468
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
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
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
confusing expr if the LHS is an empty string, the RHS needs it as well.
Also, fix some typoes ("$X" rather than "X$"), and use lower-case "x",
as that's what's used elsewhere when doing that sort of thing.
svn path=/trunk/; revision=50331
"X$GCC_OPTION" so expr doesn't get confused by the GCC_OPTION that
starts with a hyphen and spit out messages like this (on FreeBSD):
checking whether we can add -fexcess-precision=fast to CXXFLAGS... expr:
illegal option -- f
expr: usage: expr [-e] expression
expr: illegal option -- f
expr: usage: expr [-e] expression
no
svn path=/trunk/; revision=50330
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
flags, if the option should be added to the flags for both C and C++,
test both the C and C++ compilers and, if the answers are different,
print a warning; the user might have (intentionally or unintentionally)
selected mismatched compilers, e.g. clang and g++ on OS X.
svn path=/trunk/; revision=50219
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
Enable INET6 checking on Solaris versions other than 5.8.
(Yes, theoretically this should be checking for Solaris 5.7 or later. I'm
going to go out on a limb and assume that no one is actually still using 5.7
or, if they are, they aren't trying to compile a modern Wireshark on it...)
svn path=/trunk/; revision=50173
(Debian squeeze installs lua includes in /usr/include/lua5.1 and libs
under /usr/lib, there's no --with-lua=<dir> setting for this
configuration)
see also https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8438
svn path=/trunk/; revision=48146
are built with warnings.
Also add compiler-specific flags (in this case, just the flags to enable
ANSI C compilation) to CFLAGS_FOR_BUILD.
svn path=/trunk/; revision=47479
exists by doing:
if test "x$3" != "x" ; then
because if the program contains quotes it breaks the shell's parsing.
Instead test for the existence of $4 (which is mandatory if $3 is given).
Fix up the test program for -Wlogical-op so that it actually compiles
warning-free (at least on my system) when the compiler doesn't have the bug
we're checking for.
svn path=/trunk/; revision=46926
it do an additional check, if it finds that a given compiler option is
supported by the compiler, to see whether it's supported but
undesirable. The arguments are a chunk of code to try to compile with
-Werror, and a string to be used in the "checking..." message printed
when trying to compile the cunk of code.
Try enabling -Wshadow again, but have it check whether
extern int atoi(char *p);
int
foo(char *p)
{
int (*fptr)(char *p) = atoi;
return fptr(p) * 2;
}
compiles with -Wshadow and -Werror, so that we don't use -Wshadow with
compilers that complain about that; some older versions of GCC complain
about that, and it's really not worth our effort to eliminate or rename
arguments in function prototypes to make -Wshadow work even with those
compilers.
svn path=/trunk/; revision=46475
The modification to acinclude.m4 adds a new test in the
AC_WIRESHARK_OSX_INTEGRATION_CHECK section to first look for the library
gtkmacintegration. "gtkmacintegration" is the new internal name for GTK+ MAC
OSX library after the project was moved to www.gtk.org. Previously this
library was known as igemacintegration.
The patches to the three gtk/*.c files update the conditional #include
<gtkmacintegration/gtkosxapplication.h> to use the new folder name. The
Option 1 patch will break any build environment that expects to find the
gtkosapplication.h file in the older igemacintegration folder.
In addition the patch includes updates to
gtk/main.c and gtk/main_menubar.c for a more standard looking App menu.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6702
svn path=/trunk/; revision=45869
Fixes Bug #7449: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7449
-----
Issue:
Building Wireshark with '-O0 -D_FORTIFY_SOURCE=2 ...' fails
The warning [error] message:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires
compiling with optimization (-O) [-Werror=cpp]`
A bit of research shows that this warning was added to a recent version of
glibc (on at least Fedora).
See: http://sourceware.org/bugzilla/show_bug.cgi?id=13979
The warning message occurs if -D_FORTIFY_SOURCE=... is used and the gcc
'optimization level' == 0 (-O0).
Unfortunately when building with -O0 this warning message:
1. Causes compiles to fail (if -Werror [stop on warning])
2. Causes ./configure to fail with an (incorrect) message
about the pcap header being older than the libpcap version.
svn path=/trunk/; revision=43601
write bits turned off or, on 4.4-Lite-based systems, has its "user
immutable" bit turned on, ask them if they really want to overwrite the
file (as those are both used to say "this file is precious, don't let me
easily accidentally trash it") and, if the "user immutable" bit is set,
turn it off first so that the move in the "safe save" won't fail.
svn path=/trunk/; revision=43006
make them apply to C++ as well as C. That seems to be what the autoconf
documentation suggests:
- Variable: CFLAGS
Debugging and optimization options for the C compiler. If it is not set
in the environment when configure runs, the default value is set when
you call AC_PROG_CC (or empty if you don't). configure uses this
variable when compiling or linking programs to test for C features.
If a compiler option affects only the behavior of the preprocessor
(e.g., -Dname), it should be put into CPPFLAGS instead. If it affects
only the linker (e.g., -Ldirectory), it should be put into LDFLAGS
instead. If it affects only the compiler proper, CFLAGS is the natural
home for it. If an option affects multiple phases of the compiler,
though, matters get tricky. One approach to put such options directly
into CC, e.g., CC='gcc -m64'. Another is to put them into both CPPFLAGS
and LDFLAGS, but not into CFLAGS.
...
- Variable: CPPFLAGS
Preprocessor options for the C, C++, Objective C, and Objective C++
preprocessors and compilers. If it is not set in the environment when
configure runs, the default value is empty. configure uses this variable
when preprocessing or compiling programs to test for C, C++, Objective
C, and Objective C++ features.
This variable's contents should contain options like -I, -D, and -U that
affect only the behavior of the preprocessor. Please see the explanation
of CFLAGS for what you can do if an option affects other phases of the
compiler as well.
svn path=/trunk/; revision=41593
indicate whether the flag is C-only, C++-only, or for both compilers;
pass the appropriate value for C-only flags. Have the "Checking for..."
message indicate whether we're adding to CFLAGS, CXXFLAGS, or both.
(Yes, the macro should probably be renamed. "GCC" refers to the GNU
Compiler Collection, which includes a C++ compiler, although that's also
used for compilers that are more-or-less compatible with the ones from
the GNU Compiler Collection, such as the clang compilers.)
We set -Wformat-security whether or not --enable-extra-gcc-checks was
specified, so we don't need to do it again if it was specified.
svn path=/trunk/; revision=41586
UN*Xes (Fedora 16 and probably other Linux distributions, probably at
least some if not all other ELF-based systems, and perhaps also Mac OS
X), and causes problems if pcap_version[] has a different length in the
libpcap with which the executable was built and the libpcap with which
it's run, so we avoid using it for now.
svn path=/trunk/; revision=40138
When testing if we can add things to LDFLAGS, don't set LDFLAGS to CFLAGS
if the test determines that the flag cannot be added to LDFLAGS.
(Simple typo: LDFLAGS_saved was being set to CFLAGS instead of LDFLAGS.)
svn path=/trunk/; revision=38434
If we don't find python-config, set want_python to no, so the
end-of-configuration message says we're not using the Python
interpreter. Also fix some cases where we were setting want_zlib rather
than want_python (cut-and-pasteo).
svn path=/trunk/; revision=37654
items.
Add some quoting to the zlib tests, just in case the argument contains
white space.
Clean up capitalization of Lua and Python.
Link programs that use libwireshark with the Python libraries, and build
Epan with the Python cflags.
svn path=/trunk/; revision=37652
need to use its presence in zlib as a proxy for "not the crufty old zlib
that comes with some versions of X11".
Do, however, check for inflatePrime() there, instead, just in case the
crufty old zlib that comes with some versions of X11 lack it; this is to
prevent the configure script from assuming a shiny new zlib by testing
with a non-X11 program, causing the build to fail when you build
Wireshark.
svn path=/trunk/; revision=36969
ac_supports_gcc_flags and ac_supports_W_linker_passthrough flags, the
first of which, for now, we set for GCC and clang, and the latter of
which we set for GCC, clang, and xlc (probably true for some other
compilers as well).
Rename AC_WIRESHARK_GCC_LDFLAGS_CHECK to AC_WIRESHARK_LDFLAGS_CHECK, as
it's not checking for anything GCC-specific. (Leave
AC_WIRESHARK_GCC_CFLAGS_CHECK unrenamed for now, as the flags we test
with it are originally GCC flags that clang also supports for GCC
compatibility.)
Fix some string-equality tests to use = rather than ==; the former is
what the test/[ command uses.
Don't turn on "-no-cpp-precomp" for clang - it whines if you do.
svn path=/trunk/; revision=36731
"supports GCC-style -W flags", etc., and may want to improve the check
for "is this clang", as well as deciding what other stuff should be done
if we have clang as well. clang should, I think, largely be
gcc-compatible at the command line.
svn path=/trunk/; revision=36729
ones; it appears that at least one user's -ligemacintegration has both
(see bug 4823), and we should choose the new ones in that case.
Also, always set have_ige_mac if we have the functions.
Fix tpyoes while we're at it.
svn path=/trunk/; revision=33106
Call the various flavors of OS X integration just "OS X integration",
not anything with "IGE" in it - it appears that, in some places,
"ige-mac-integration" refers only to the older Carbon-based functions,
although the library still appears to be called -ligemacintegration.
Update the URLs for the information about the OS X integration
libraries.
Clean up help message for --with-pcap-remote.
Clean up white space a bit.
Speaking of white space, it's "Mac OS X", not "MacOS X".
svn path=/trunk/; revision=32941
pcap_set_buffer_size() did as well, so there aren't any libpcap releases
with pcap_create() but not pcap_set_buffer_size().
Only do one check for pcap_create.
svn path=/trunk/; revision=32695
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=475
BUT not activating the check for
pcap_create()
pcap_set_buffer_size()
This should make it possible to build with support for setting the buffersize if not capturing 802.11 traffic.
The code for handling the 'B' option should be OK in any case.
svn path=/trunk/; revision=32688
Using pcap create and pcap_activate should make it possible
to set the capture buffer size on Linux systems as well as Windows.
Help to implement it would be apreciated :-)
Ref:
http://seclists.org/tcpdump/2009/q3/151
svn path=/trunk/; revision=32687
substitute our own (I wrote them all, so I can steal them from the
BSD-licensed libpcap if I want :-)). This means that
linktype_name_to_val() and linktype_val_to_name() are always available,
and we don't need to #ifdef use of them.
Use pcap_datalink_val_to_description() to get the description for a
particular DLT_ value, rather than mapping the DLT_ value to a
WTAP_ENCAP_ value and getting the description for the latter.
svn path=/trunk/; revision=27074
back to what they were before the test (without GTK_LIBS).
This prevents tshark (and every other program) from unnecessarily linking
against GTK_LIBS.
svn path=/trunk/; revision=27056
