Use the header file for information about LINKTYPE_NFLOG files.
Don't build the NFLOG printer if we don't have that header file.
Fix some checks for pcap/XXX.h header files to look for
"tcpdump-stdinc.h" rather than <tcpdump-stdinc.h>, so that we don't fail
to find that header.
Don't check whether we can create a TCP-over-IPv6 socket; that appears
to fail in some cases where tcpdump can be built with IPv6 support.
Instead, just check whether AF_INET6 and struct in6_addr are defined.
Now that we're requiring autoconf 2.61 or later, AC_PROG_CC sets -g
along with -O2 for GCC-like compilers regardless of whether .devel is
present. Add "include debugging symbols" options for MIPS C/DEC C
regardless of whether .devel is present; that's -g3, which is the
version that doesn't turn optimization off (we also turn on -O).
Also, don't change the ABI on IRIX depending on .devel.
I'm not sure why we were doing that; if somebody has a good reason to
continue doing it, please let us know what it is.
Expand some comments while we're at it.
Lifted from the libpcap configure script, which adds -g even without
.devel, presumably so that programs linked with libpcap can get
debugging symbols.
Those compilers are for dead OSes (IRIX, Tru64 UNIX); we should probably
do whatever voodoo is needed to get Sun^WOracle C, IBM's C compiler for
AIX, and HP C to build optimized with debug symbols.
AC_PROG_CC adds -g and -O2 to CFLAGS if you're using GCC; don't bother
adding either of them, or -O, ourselves if we're using GCC.
Add -O for all non-GCC compilers.
Don't assume we have <stdint.h>. Instead, use the AC_TYPE_ macros to
ensure we have the C99 intN_t and uintN_t types; we already include
<inttypes.h> in tcpdump-stdinc.h iff we have it.
Get rid of the structure declarations in openflow-1.0.h, as they have
zero-length arrays (not supported by all the compilers people might be
using) and as
1) they're only used in sizeof()
and
2) after each one there's an assertion to check that sizeof()
returns a specific numerical value
so, instead, just #define various _LEN items to those numerical values
and use them.
Add an openflow.h header with a #define for the length of the basic
header, and move the declaration of of10_header_body_print() there.
Some versions of Sun C support __attribute__ but don't support the
"unused" or "format" attributes - they don't fail, but they whine a lot.
They also support the "noreturn" attribute, but don't allow it to be
applied to function pointers, only to functions.
Check whether they can be used without warnings, and use them only if
they can.
autoconf 2.61 and later do, in AC_PROG_CC, tests to figure out how to
beat non-GCC compilers into doing the closest thing to ANSI C of which
they're capable, so we don't need to do them ourselves.
MIPS C and DEC C also can't be made to reliably Just Say No to those
flags, and they don't support those flags, so don't try them with those
compilers either.
HP's C compiler cannot be made to exit with a non-zero exit status when
given an unknown compiler flag, so you can't use that to figure out if a
flag is supported, but it *will* print a warning, which we don't want.
In addition, it doesn't support -W flags for warnings in any case, so
let's not bother with them.
Don't base the question of whether to use a particular -W flag on
whether we're compiling with GCC or not, and on which version of GCC
we're using; some compilers, such as clang, also support many of those
-W flags. Base it on whether the compiler complains if we use it (which
means, for clang, that we have to force it to exit with a non-zero exit
status if it doesn't like a flag; otherwise, we'll specify it, and clang
will warn about it on every compile).
On some platforms, such as SunOS 5.x, building the "do we have IPv6
support?" test program requires the extra networking libraries, so we
need to know what extra networking libraries are required before doing
that test.
macros rather than a local copy of AC_LBL_SSLEAY.
AC_LBL_SSLEAY is old and has not kept pace with some more recent
developments in packaging like Debian and Ubuntu's multiarch support.
The autoconf macros have been updated to handle multiarch so using them
means that tcpdump gains the ability to be built with libcrypto on these
new multiarch distros and to work successfully with Travis CI, which
uses Ubuntu 12, which is one such multiarch distro (see GH-32).
Fixes GH-33
...so that we can see what's being used to turn grammar.y into
grammar.c.
While we're at it, say "config.log file from the libpcap source
directory", in the hopes of making it more likely that we'll get it in
addition to the tcpdump config.log.
I give up.
People keep reporting that the configure process for tcpdump fails to
find pcap_loop, and the config.log file they send us says there's no
pcap_parse in libpcap, which suggests that something went wrong in the
build process for libpcap; perhaps they don't have Bison and the
configure script got confused and failed to cause the parser to be named
"pcap_parse", or something such as that, or perhaps Bison was recently
"improved" in a fashion that breaks that, but I've never been able to
reproduce this on any of the Linux distribution installations to which
*I* have access.
I therefore ask them to send the config.log output and make output for
libpcap; *not one of the reporters of this problem* has bothered to send
that information, so we're stuck. Perhaps they don't care enough (in
which case, why did they bother asking us about it?), or perhaps they're
annoyed that we asked them a further question rather than Just Fixing
The Problem(TM) (in which case, all I have to say is "welcome to the
Wonderful World Of Computer Software(TM) - get used to it").
So let's just ask for all that information. (I would not be surprised
if this doesn't suffice and that they *still* just send us the tcpdump
config.log output, but at least I'll be able to tell them that they
should have Read The Fine Error Message(TM).)
Unfortunately, the DLT_PFSYNC support depends on header files included
from the pfctl command's source tree, and trying to arrange to find that
would be too much trouble.
From FreeBSD PR bin/124825: tcpdump(8) does not support pfsync(4) data,
which in turn was ported over from OpenBSD. We already have CARP
support, so we did not port that part over.
Glibc 2.14 doesn't install the ONC RPC headers, but it installs the ONC
RPC routines, presumably for binary compatibility. Don't use
getrpcbynumber() unless we have it *and* the header file to declare it.
Now that we're setting V_INCLS correctly, we don't need to include
"tcpdump-stdinc.h" - including <tcpdump-stdinc.h> works.
This also picks up configure changes from the previous configure.in
change.
Doing it at make time means you don't have to re-run the configure
script if you add uudecode to your system, and doing it by uudecoding a
uuencoded empty file means we don't depend on uudecode supporting
"--help".
Instead, check for uudecode in the configure script, and set the
CHECK_UUDECODE configuration variable to "true" if we find it and to a
command that prints an error message and exits with 1 if we don't find
it, and substitute that variable into the Makefile as the first command
for "make check".
This also fixes configure-script problems on OSes that have IPv6 support
but don't have <netinet6/in6.h> - no standard I could find requires that
header for IPv6 support (the Single UNIX Specification speaks of
<netinet/in.h> for both IPv4 and IPv6, and RFCs 2292 and 3542 don't
mention <netinet6/in6.h>, just <netinet/in.h> and <netinet6/ip6.h>).
See section 11.6 "Shell Substitutions" in the autoconf documentation,
especially the
There is just no portable way to use double-quoted strings
inside double-quoted back-quoted expressions (pfew!).
part.
Rather than hardcode the WIN32 define, add proper fork checks to the
configure script and check those. This fixes building for nommu systems
which lack the fork function.
While we're here though, add support for this functionality via vfork
so that it does work on nommu systems. And fix an old bug where we
exit properly in the forked child when the exec failed instead of just
returning to the calling code (which isn't expecting it).
Reviewed-By: Guy Harris <guy@alum.mit.edu>
The PROG variant does not take into consideration cross-compilation, so
it always looks for "pcap-config" which finds the host script. So use
the TOOL variant instead which first searches for the cross-prefixed
pcap-config before falling back to the bare "pcap-config".
Reviewed-By: Guy Harris <guy@alum.mit.edu>
After finding libpcap and getting a list of other flags needed when
linking, we check for "pcap_loop()", to make sure we found a working
libpcap and have all the right other libraries with which dnl to link.
(Otherwise, for example, the check for pcap_list_datalinks() will fail,
not because the routines are missing from the library, but because we
aren't linking properly with libpcap, and that will cause confusing
errors at build time.)
