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
Guy Harris