On Solaris 10 /usr/bin/grep does not implement the -q flag:
checking for pcap-config... ../libpcap/pcap-config
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
checking for pcap_loop... yes
Follow recommendation of the "Limitations of Usual Tools" section of GNU
Autoconf manual and use output redirection to fix it:
checking for pcap-config... ../libpcap/pcap-config
checking for pcap_loop... yes
THat forces *all* uses of the C compiler, whether it's being used in
configure-script tests or used to compile tcpdump, to gave -fPIC, which
is necessary on Haiku in order for linking to work. Otherwise,
configure script tests that involve linking will fail.
POSIX does not require that a system support egrep; it requires that it
support grep -E. In AC_LBL_LIBPCAP, use AC_PROG_EGREP to check for a
command that supports egrep-style expressions, and use $EGREP rather
than egrep in subsequent commands.
This squelches warnings on platforms where egrep prints a warning
suggesting that grep -E be used instead.
configure: WARNING: can't find lbl/os-darwin22.h
configure: WARNING: can't find lbl/os-freebsd13.h
configure: WARNING: can't find lbl/os-linux-gnu.h
configure: WARNING: can't find lbl/os-netbsd9.h
configure: WARNING: can't find lbl/os-openbsd7.h
It is not clear why the os-proto.h symlink management logic is
conditional on the .devel file, but it is clear that nowadays supported
platforms tend not to need a custom header file. Thus absence of the
file should not generate a warning, also it would be useful to note its
presence. With this in mind, convert the warning into a template
message:
(config.guess prints "x86_64-pc-linux-gnu" on a Linux PC.)
checking whether to use an os-proto.h header... no
(config.guess prints "sparc-sun-solaris2.10" on a Solaris 10 host.)
checking whether to use an os-proto.h header... yes, at
"lbl/os-solaris2.h"
In 2002 this macro implemented a workaround for HP C compiler because
the latter did not work with the implementation of AC_C_INLINE in
Autoconf 2.13 (see commit b1263c6). Since then the required kind of
inline very likely became available in every supported compiler of every
supported OS, but just in case there is still an exception, use
AC_C_INLINE from Autoconf 2.69 (or later) and trust it to work right.
In other words, if the original problem still exists, this will have to
be proven.
This squelches one more warning from Autoconf 2.71:
configure.ac:32: warning: The macro `AC_TRY_COMPILE' is obsolete.
Remove a copyright boilerplate that stood for IPv6 macros added via
commit c9d84d1 in 1999 and removed via commit 11f73ad in 2015. Remove
AC_LBL_SSLEAY, which is unused and obsolete. This change does not
result in any changes in any other files.
AC_LBL_FIXINCLUDES, AC_LBL_UNION_WAIT and AC_LBL_HAVE_RUN_PATH have no
purpose in this source tree. AC_LBL_SHLIBS_INIT does not exist. This
change does not introduce meaningful changes in any other files.
We use gethostbyaddr() to translate IP addresses in packets to names; we
don't use gethostbyname() to translate names to IP addresses (libpcap
does the latter when compiling filters, so we leave that up to it, and
nothing's left for us to do).
This probably has the same effect as checking for gethostbyname(), but
it makes it a bit clearer why we'd check for it.
If we're linking with a libpcap in ../libpcap*, it's static, but we only
need to link with the libraries on wich it immediately depends, we don't
need to link with the libraries on which those libraries depend, etc..
So, if ../libpcap*/pcap-config supports --static-pcap-only, use that.
There are two versions of pcap-config supplied on Solaris (or, at least,
on 64-bit Solaris) - a version that has the right --libs output to find
the 32-bit libraries and a version that has the right --libs output to
find the 64-bit libraries.
Try to figure out whether we're doing a 32-bit or 64-bit build (based on
the pointer size) and, for 64-bit builds, run the 64-bit version of
pcap-config.
macOS's /usr/bin/pcap-config is incorrectly generated - pcap-config
--cflags includes -I/usr/local/include and pcap-config --libs includes
-L/usr/local/lib, even though it's the pcap-config file for the libpcap
that comes with the OS and should omit those.
That lets us completely control the program that's compiled with the
compiler flag we're testing, so we can make it a minimal program that
uses only prototype declarations and that therefore won't generate
warnings with some -W flags, e.g. -Wold-style-definition, and thus won't
falsely report those flags as unsupported.
It's not a documented feature, but it's what the documented
AC_LANG_WERROR has used for 13 years, and there's no push/pop mechanism
for AC_LANG_WERROR, so you can't ensure that "fail even on warnings"
will be applied *only* in AC_LBL_CHECK_COMPILER_OPT(), as that's what we
want. (If we can make sure that *no* compiler tests will produce
warnings, except for the ones we *want* to fail if they produce
warnings, we could just do AC_LANG_WERROR, but that might be tricky to
ensure in the general case.)
We do this because not all compilers have a command-line flag to force
all warnings, *including* warnings from unknown commad-line flags (I'm
looking at *you* IBM XL C!), so we have to have the test check to make
sure no warnings are produced (which, for AC_TRY_COMPILE(), means
"nothing is written to the standard output").
In addition, AC_TRY_COMPILE() generates a return; don't add one:
If we pass [return 0] to AC_TRY_COMPILE(), the test program it compiles
has two "return 0;" statements in a row, and one of the -W flags we
tests reports a warning for that.
We were testing whether a -W flag is supported by checking the standard
error of the compiler to see if *any* error/warning messages are
generated, and treating the flag as unsupported if any are, that meant
that -Wunreachable-code-return was be treated as unsupported even though
it *is* supported.
This should fix that. (I'm so glad autoconf makes this all so difficult
to do correctly....)
--with-system-libpcap didn't work - it didn't prevent searching for a
local libpcap - and had a misleading name. Replace it with
--disable-local-libpcap.
This should address GitHub issue #823.
I can't seem to make those issues pop up on my (x86-64) machine, and, if
they do show up on any platforms, the best hack to handle it is probably
to have a special tcpdump flag to force it to do a floating-point
calculation and see what result is generated, and report the result, so
we know what it'll do with the numbers in the test files, and have
tests/TESTrun run tcpdump with that flag.
If those tests *do* fail, we'll know what calculations to do.
If we have pkg-config, *and* it has .pc files for libpcap, use it to get
the C compiler flags and linker flags for libpcap.
find_library() sets a cache variable; when we're looping over libraries,
trying to find their full paths, we really want the variable to act as a
local variable, as we're looking up different libraries, so unset it
after we're finished processing a particular library.
When we're searching for static libraries, save the current value of
CMAKE_FIND_LIBRARY_SUFFIXES, set it to ".a", and then restore it when
we're done. Don't use cmake_push_check_state() for that, as
CMAKE_FIND_LIBRARY_SUFFIXES is *not* one of the variables that it's
guaranteed to save and restore.
Instead, use compiler test macros to check whether *particular*
attributes are supported, and set various #defines appropriately, in
header files.
Rename the UNALIGNED structure attribute to ND_UNALIGNED, and ask
whether we still need it.
We have four possibilities:
1) local library, with a pcap-config;
2) local library, without a pcap-config;
3) installed library, with a pcap-config;
4) installed library, without a pcap-config.
If we have a local library, i.e. one in ../libpcap{whatever}, we:
add -I flags to the C compiler flags to point it at whatever
directories in ../libpcap{whatever};
add ../libpcap{whatever}/libpcap.a to $LIBS and:
if it has a pcap-config, we use it, with --additional-libraries,
to find the additional libraries with which we need to link;
otherwise, we do the usual OS-dependent hacks to try to figure
out with what additional flags we need to link;
and add them to $LIBS after libpcap.a.
If we have an installed library:
if it has a pcap-config we use it, with --cflags, to find what flags
to add to the C compiler flags, and use it, with --libs, to see what
flags to add to $LIBS;
if it doesn't have a pcap-config, we search for -lpcap and, if that
succeeds, we assume the headers are under /usr/local/include or
/usr/include, search for them there, and, if we don't find pcap.h
there, we look for it in a pcap subdirectory under there, and add
the appropriate -I flag to the C compiler flags, and then do the
usual OS-dependent hacks to try to figure out with what additional
flags we need to link.
While we're at it, we do the libdlpi check only on Solaris, as part of
"the usual OS-dependent hacks".
Some time between the mid 1980's and 1990 called; they want their
old-fashioned UNIX signal handling back. ANSI C has had signal handlers
returning void sincer, well, 1989, and POSIX has had sigaction() since
close to forever. No need to worry about really old UN*Xes here.
On Windows, it's also void (as per ANSI C); use signal().
