1999-10-08 07:47:09 +08:00
|
|
|
dnl Copyright (c) 1995, 1996, 1997, 1998
|
|
|
|
dnl The Regents of the University of California. All rights reserved.
|
|
|
|
dnl
|
|
|
|
dnl Redistribution and use in source and binary forms, with or without
|
|
|
|
dnl modification, are permitted provided that: (1) source code distributions
|
|
|
|
dnl retain the above copyright notice and this paragraph in its entirety, (2)
|
|
|
|
dnl distributions including binary code include the above copyright notice and
|
|
|
|
dnl this paragraph in its entirety in the documentation or other materials
|
|
|
|
dnl provided with the distribution, and (3) all advertising materials mentioning
|
|
|
|
dnl features or use of this software display the following acknowledgement:
|
|
|
|
dnl ``This product includes software developed by the University of California,
|
|
|
|
dnl Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
|
|
|
|
dnl the University nor the names of its contributors may be used to endorse
|
|
|
|
dnl or promote products derived from this software without specific prior
|
|
|
|
dnl written permission.
|
|
|
|
dnl THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
|
|
|
|
dnl WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
|
|
|
|
dnl MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
dnl
|
|
|
|
dnl LBL autoconf macros
|
|
|
|
dnl
|
|
|
|
|
|
|
|
dnl
|
2010-01-03 07:29:06 +08:00
|
|
|
dnl Do whatever AC_LBL_C_INIT work is necessary before using AC_PROG_CC.
|
1999-10-08 07:47:09 +08:00
|
|
|
dnl
|
2010-01-03 07:29:06 +08:00
|
|
|
dnl It appears that newer versions of autoconf (2.64 and later) will,
|
|
|
|
dnl if you use AC_TRY_COMPILE in a macro, stick AC_PROG_CC at the
|
|
|
|
dnl beginning of the macro, even if the macro itself calls AC_PROG_CC.
|
|
|
|
dnl See the "Prerequisite Macros" and "Expanded Before Required" sections
|
|
|
|
dnl in the Autoconf documentation.
|
1999-10-08 07:47:09 +08:00
|
|
|
dnl
|
2010-01-03 07:29:06 +08:00
|
|
|
dnl This causes a steaming heap of fail in our case, as we were, in
|
|
|
|
dnl AC_LBL_C_INIT, doing the tests we now do in AC_LBL_C_INIT_BEFORE_CC,
|
|
|
|
dnl calling AC_PROG_CC, and then doing the tests we now do in
|
|
|
|
dnl AC_LBL_C_INIT. Now, we run AC_LBL_C_INIT_BEFORE_CC, AC_PROG_CC,
|
|
|
|
dnl and AC_LBL_C_INIT at the top level.
|
1999-10-08 07:47:09 +08:00
|
|
|
dnl
|
2010-01-03 07:29:06 +08:00
|
|
|
AC_DEFUN(AC_LBL_C_INIT_BEFORE_CC,
|
2013-10-18 08:00:38 +08:00
|
|
|
[
|
2010-01-03 07:29:06 +08:00
|
|
|
AC_BEFORE([$0], [AC_LBL_C_INIT])
|
1999-10-08 07:47:09 +08:00
|
|
|
AC_BEFORE([$0], [AC_PROG_CC])
|
|
|
|
AC_BEFORE([$0], [AC_LBL_DEVEL])
|
|
|
|
AC_ARG_WITH(gcc, [ --without-gcc don't use gcc])
|
2013-10-18 07:50:43 +08:00
|
|
|
$1=""
|
1999-10-08 07:47:09 +08:00
|
|
|
if test "${srcdir}" != "." ; then
|
2013-10-18 07:50:43 +08:00
|
|
|
$1="-I$srcdir"
|
1999-10-08 07:47:09 +08:00
|
|
|
fi
|
|
|
|
if test "${CFLAGS+set}" = set; then
|
|
|
|
LBL_CFLAGS="$CFLAGS"
|
|
|
|
fi
|
|
|
|
if test -z "$CC" -a "$with_gcc" = no ; then
|
|
|
|
CC=cc
|
|
|
|
export CC
|
|
|
|
fi
|
2010-01-03 07:29:06 +08:00
|
|
|
])
|
|
|
|
|
|
|
|
dnl
|
|
|
|
dnl Determine which compiler we're using (cc or gcc)
|
|
|
|
dnl If using gcc, determine the version number
|
2013-10-18 07:50:43 +08:00
|
|
|
dnl If using cc:
|
|
|
|
dnl require that it support ansi prototypes
|
|
|
|
dnl use -O (AC_PROG_CC will use -g -O2 on gcc, so we don't need to
|
|
|
|
dnl do that ourselves for gcc)
|
2013-10-22 01:56:33 +08:00
|
|
|
dnl add -g flags, as appropriate
|
2013-10-18 07:50:43 +08:00
|
|
|
dnl explicitly specify /usr/local/include
|
2010-01-03 07:29:06 +08:00
|
|
|
dnl
|
2013-10-18 07:57:49 +08:00
|
|
|
dnl NOTE WELL: with newer versions of autoconf, "gcc" means any compiler
|
|
|
|
dnl that defines __GNUC__, which means clang, for example, counts as "gcc".
|
|
|
|
dnl
|
2010-01-03 07:29:06 +08:00
|
|
|
dnl usage:
|
|
|
|
dnl
|
|
|
|
dnl AC_LBL_C_INIT(copt, incls)
|
|
|
|
dnl
|
|
|
|
dnl results:
|
|
|
|
dnl
|
|
|
|
dnl $1 (copt set)
|
|
|
|
dnl $2 (incls set)
|
|
|
|
dnl CC
|
|
|
|
dnl LDFLAGS
|
|
|
|
dnl LBL_CFLAGS
|
|
|
|
dnl
|
|
|
|
AC_DEFUN(AC_LBL_C_INIT,
|
2013-10-18 08:00:38 +08:00
|
|
|
[
|
2010-01-03 07:29:06 +08:00
|
|
|
AC_BEFORE([$0], [AC_LBL_DEVEL])
|
1999-10-08 07:47:09 +08:00
|
|
|
if test "$GCC" = yes ; then
|
2013-06-23 05:06:33 +08:00
|
|
|
#
|
|
|
|
# -Werror forces warnings to be errors.
|
|
|
|
#
|
|
|
|
ac_lbl_cc_force_warning_errors=-Werror
|
1999-10-08 07:47:09 +08:00
|
|
|
else
|
|
|
|
$2="$$2 -I/usr/local/include"
|
|
|
|
LDFLAGS="$LDFLAGS -L/usr/local/lib"
|
|
|
|
|
2001-12-10 16:41:15 +08:00
|
|
|
case "$host_os" in
|
1999-10-08 07:47:09 +08:00
|
|
|
|
2013-06-23 05:06:33 +08:00
|
|
|
darwin*)
|
|
|
|
#
|
|
|
|
# This is assumed either to be GCC or clang, both
|
|
|
|
# of which use -Werror to force warnings to be errors.
|
|
|
|
#
|
2023-02-12 16:35:48 +08:00
|
|
|
# XXX - they also both cause GCC to be set to yes,
|
|
|
|
# so we should never get here in the first place.
|
|
|
|
#
|
2013-06-23 05:06:33 +08:00
|
|
|
ac_lbl_cc_force_warning_errors=-Werror
|
|
|
|
;;
|
|
|
|
|
2013-05-08 14:58:51 +08:00
|
|
|
hpux*)
|
|
|
|
#
|
2013-05-13 03:30:01 +08:00
|
|
|
# HP C, which is what we presume we're using, doesn't
|
|
|
|
# exit with a non-zero exit status if we hand it an
|
|
|
|
# invalid -W flag, can't be forced to do so even with
|
|
|
|
# +We, and doesn't handle GCC-style -W flags, so we
|
|
|
|
# don't want to try using GCC-style -W flags.
|
2013-05-08 14:58:51 +08:00
|
|
|
#
|
2013-05-13 03:30:01 +08:00
|
|
|
ac_lbl_cc_dont_try_gcc_dashW=yes
|
2013-05-08 14:58:51 +08:00
|
|
|
;;
|
|
|
|
|
2013-06-23 05:06:33 +08:00
|
|
|
solaris*)
|
|
|
|
#
|
|
|
|
# Assumed to be Sun C, which requires -errwarn to force
|
|
|
|
# warnings to be treated as errors.
|
|
|
|
#
|
|
|
|
ac_lbl_cc_force_warning_errors=-errwarn
|
|
|
|
;;
|
1999-10-08 07:47:09 +08:00
|
|
|
esac
|
2013-10-18 07:50:43 +08:00
|
|
|
$1="$$1 -O"
|
1999-10-08 07:47:09 +08:00
|
|
|
fi
|
|
|
|
])
|
|
|
|
|
2013-05-07 14:54:20 +08:00
|
|
|
dnl
|
|
|
|
dnl Check whether the compiler option specified as the second argument
|
|
|
|
dnl is supported by the compiler and, if so, add it to the macro
|
|
|
|
dnl specified as the first argument
|
|
|
|
dnl
|
|
|
|
AC_DEFUN(AC_LBL_CHECK_COMPILER_OPT,
|
|
|
|
[
|
|
|
|
AC_MSG_CHECKING([whether the compiler supports the $2 option])
|
|
|
|
save_CFLAGS="$CFLAGS"
|
configure: use ac_c_werror_flag to force unknown compiler flags to fail.
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....)
2021-07-25 17:22:42 +08:00
|
|
|
CFLAGS="$CFLAGS $2"
|
|
|
|
#
|
|
|
|
# XXX - yes, this depends on the way AC_LANG_WERROR works,
|
|
|
|
# but no mechanism is provided to turn AC_LANG_WERROR on
|
|
|
|
# *and then turn it back off*, so that we *only* do it when
|
|
|
|
# testing compiler options - 15 years after somebody asked
|
|
|
|
# for it:
|
|
|
|
#
|
|
|
|
# https://autoconf.gnu.narkive.com/gTAVmfKD/how-to-cancel-flags-set-by-ac-lang-werror
|
|
|
|
#
|
|
|
|
save_ac_c_werror_flag="$ac_c_werror_flag"
|
|
|
|
ac_c_werror_flag=yes
|
|
|
|
#
|
2021-07-25 18:02:54 +08:00
|
|
|
# We use AC_LANG_SOURCE() so that we can control the complete
|
|
|
|
# content of the program being compiled. We do not, for example,
|
|
|
|
# want the default "int main()" that AC_LANG_PROGRAM() generates,
|
|
|
|
# as it will generate a warning with -Wold-style-definition, meaning
|
|
|
|
# that we would treat it as not working, as the test will fail if
|
|
|
|
# *any* error output, including a warning due to the flag we're
|
|
|
|
# testing, is generated; see
|
configure: use ac_c_werror_flag to force unknown compiler flags to fail.
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....)
2021-07-25 17:22:42 +08:00
|
|
|
#
|
2021-07-25 18:02:54 +08:00
|
|
|
# https://www.postgresql.org/message-id/2192993.1591682589%40sss.pgh.pa.us
|
|
|
|
# https://www.postgresql.org/message-id/2192993.1591682589%40sss.pgh.pa.us
|
configure: use ac_c_werror_flag to force unknown compiler flags to fail.
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....)
2021-07-25 17:22:42 +08:00
|
|
|
#
|
2022-07-04 17:58:59 +08:00
|
|
|
# This may, as per those two messages, be fixed in autoconf 2.70,
|
2023-03-27 07:47:32 +08:00
|
|
|
# but we only require 2.69 or newer for now.
|
configure: use ac_c_werror_flag to force unknown compiler flags to fail.
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....)
2021-07-25 17:22:42 +08:00
|
|
|
#
|
2021-07-25 18:02:54 +08:00
|
|
|
AC_COMPILE_IFELSE(
|
|
|
|
[AC_LANG_SOURCE([[int main(void) { return 0; }]])],
|
2013-05-07 14:54:20 +08:00
|
|
|
[
|
|
|
|
AC_MSG_RESULT([yes])
|
|
|
|
CFLAGS="$save_CFLAGS"
|
|
|
|
$1="$$1 $2"
|
|
|
|
],
|
|
|
|
[
|
|
|
|
AC_MSG_RESULT([no])
|
|
|
|
CFLAGS="$save_CFLAGS"
|
|
|
|
])
|
configure: use ac_c_werror_flag to force unknown compiler flags to fail.
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....)
2021-07-25 17:22:42 +08:00
|
|
|
ac_c_werror_flag="$save_ac_c_werror_flag"
|
2013-05-07 14:54:20 +08:00
|
|
|
])
|
|
|
|
|
2013-05-08 15:08:12 +08:00
|
|
|
dnl
|
|
|
|
dnl Check whether the compiler supports an option to generate
|
|
|
|
dnl Makefile-style dependency lines
|
|
|
|
dnl
|
|
|
|
dnl GCC uses -M for this. Non-GCC compilers that support this
|
|
|
|
dnl use a variety of flags, including but not limited to -M.
|
|
|
|
dnl
|
|
|
|
dnl We test whether the flag in question is supported, as older
|
|
|
|
dnl versions of compilers might not support it.
|
|
|
|
dnl
|
|
|
|
dnl We don't try all the possible flags, just in case some flag means
|
|
|
|
dnl "generate dependencies" on one compiler but means something else
|
|
|
|
dnl on another compiler.
|
|
|
|
dnl
|
|
|
|
dnl Most compilers that support this send the output to the standard
|
|
|
|
dnl output by default. IBM's XLC, however, supports -M but sends
|
|
|
|
dnl the output to {sourcefile-basename}.u, and AIX has no /dev/stdout
|
|
|
|
dnl to work around that, so we don't bother with XLC.
|
|
|
|
dnl
|
|
|
|
AC_DEFUN(AC_LBL_CHECK_DEPENDENCY_GENERATION_OPT,
|
|
|
|
[
|
|
|
|
AC_MSG_CHECKING([whether the compiler supports generating dependencies])
|
|
|
|
if test "$GCC" = yes ; then
|
|
|
|
#
|
|
|
|
# GCC, or a compiler deemed to be GCC by AC_PROG_CC (even
|
|
|
|
# though it's not); we assume that, in this case, the flag
|
|
|
|
# would be -M.
|
|
|
|
#
|
|
|
|
ac_lbl_dependency_flag="-M"
|
|
|
|
else
|
|
|
|
#
|
|
|
|
# Not GCC or a compiler deemed to be GCC; what platform is
|
|
|
|
# this? (We're assuming that if the compiler isn't GCC
|
|
|
|
# it's the compiler from the vendor of the OS; that won't
|
|
|
|
# necessarily be true for x86 platforms, where it might be
|
|
|
|
# the Intel C compiler.)
|
|
|
|
#
|
|
|
|
case "$host_os" in
|
|
|
|
|
2024-01-29 00:48:31 +08:00
|
|
|
darwin*)
|
2013-05-08 15:08:12 +08:00
|
|
|
#
|
2024-01-29 00:48:31 +08:00
|
|
|
# Clang uses -M.
|
2013-05-08 15:08:12 +08:00
|
|
|
#
|
|
|
|
ac_lbl_dependency_flag="-M"
|
|
|
|
;;
|
|
|
|
|
|
|
|
solaris*)
|
|
|
|
#
|
|
|
|
# Sun C uses -xM.
|
|
|
|
#
|
|
|
|
ac_lbl_dependency_flag="-xM"
|
|
|
|
;;
|
|
|
|
|
|
|
|
hpux*)
|
|
|
|
#
|
|
|
|
# HP's older C compilers don't support this.
|
|
|
|
# HP's newer C compilers support this with
|
|
|
|
# either +M or +Make; the older compilers
|
|
|
|
# interpret +M as something completely
|
|
|
|
# different, so we use +Make so we don't
|
|
|
|
# think it works with the older compilers.
|
|
|
|
#
|
|
|
|
ac_lbl_dependency_flag="+Make"
|
|
|
|
;;
|
|
|
|
|
|
|
|
*)
|
|
|
|
#
|
|
|
|
# Not one of the above; assume no support for
|
|
|
|
# generating dependencies.
|
|
|
|
#
|
|
|
|
ac_lbl_dependency_flag=""
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
|
|
|
|
#
|
|
|
|
# Is ac_lbl_dependency_flag defined and, if so, does the compiler
|
|
|
|
# complain about it?
|
|
|
|
#
|
|
|
|
# Note: clang doesn't seem to exit with an error status when handed
|
|
|
|
# an unknown non-warning error, even if you pass it
|
|
|
|
# -Werror=unknown-warning-option. However, it always supports
|
|
|
|
# -M, so the fact that this test always succeeds with clang
|
|
|
|
# isn't an issue.
|
|
|
|
#
|
|
|
|
if test ! -z "$ac_lbl_dependency_flag"; then
|
|
|
|
AC_LANG_CONFTEST(
|
|
|
|
[AC_LANG_SOURCE([[int main(void) { return 0; }]])])
|
2018-01-23 12:51:51 +08:00
|
|
|
if AC_RUN_LOG([eval "$CC $ac_lbl_dependency_flag conftest.c >/dev/null 2>&1"]); then
|
2013-05-08 15:08:12 +08:00
|
|
|
AC_MSG_RESULT([yes, with $ac_lbl_dependency_flag])
|
|
|
|
DEPENDENCY_CFLAG="$ac_lbl_dependency_flag"
|
2020-03-03 08:15:07 +08:00
|
|
|
MKDEP='${top_srcdir}/mkdep'
|
2013-05-08 15:08:12 +08:00
|
|
|
else
|
|
|
|
AC_MSG_RESULT([no])
|
|
|
|
#
|
|
|
|
# We can't run mkdep, so have "make depend" do
|
|
|
|
# nothing.
|
|
|
|
#
|
|
|
|
MKDEP=:
|
|
|
|
fi
|
|
|
|
rm -rf conftest*
|
|
|
|
else
|
|
|
|
AC_MSG_RESULT([no])
|
|
|
|
#
|
|
|
|
# We can't run mkdep, so have "make depend" do
|
|
|
|
# nothing.
|
|
|
|
#
|
|
|
|
MKDEP=:
|
|
|
|
fi
|
2013-05-13 07:37:47 +08:00
|
|
|
AC_SUBST(DEPENDENCY_CFLAG)
|
|
|
|
AC_SUBST(MKDEP)
|
2013-05-08 15:08:12 +08:00
|
|
|
])
|
|
|
|
|
1999-10-08 07:47:09 +08:00
|
|
|
dnl
|
|
|
|
dnl Require libpcap
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
dnl Look for libpcap in directories under ..; those are local versions.
|
|
|
|
dnl Look for an installed libpcap if there is no local version or if
|
|
|
|
dnl the user said not to look for a local version.
|
1999-10-08 07:47:09 +08:00
|
|
|
dnl
|
|
|
|
dnl usage:
|
|
|
|
dnl
|
|
|
|
dnl AC_LBL_LIBPCAP(pcapdep, incls)
|
|
|
|
dnl
|
|
|
|
dnl results:
|
|
|
|
dnl
|
|
|
|
dnl $1 (pcapdep set)
|
|
|
|
dnl $2 (incls appended)
|
|
|
|
dnl LIBS
|
|
|
|
dnl
|
|
|
|
AC_DEFUN(AC_LBL_LIBPCAP,
|
2023-02-12 18:23:18 +08:00
|
|
|
[
|
|
|
|
AC_REQUIRE([AC_PROG_EGREP])
|
|
|
|
AC_REQUIRE([AC_LBL_LIBRARY_NET])
|
2017-11-14 10:55:32 +08:00
|
|
|
libpcap=FAIL
|
2020-07-20 11:12:32 +08:00
|
|
|
AC_MSG_CHECKING([whether to look for a local libpcap])
|
|
|
|
AC_ARG_ENABLE(local-libpcap,
|
|
|
|
AS_HELP_STRING([--disable-local-libpcap],
|
|
|
|
[don't look for a local libpcap @<:@default=check for a local libpcap@:>@]),,
|
|
|
|
enableval=yes)
|
|
|
|
case "$enableval" in
|
|
|
|
|
|
|
|
no)
|
|
|
|
AC_MSG_RESULT(no)
|
|
|
|
#
|
|
|
|
# Don't look for a local libpcap.
|
|
|
|
#
|
|
|
|
using_local_libpcap=no
|
|
|
|
;;
|
2020-08-01 18:04:52 +08:00
|
|
|
|
2020-07-20 11:12:32 +08:00
|
|
|
*)
|
|
|
|
AC_MSG_RESULT(yes)
|
|
|
|
#
|
|
|
|
# Look for a local pcap library.
|
|
|
|
#
|
|
|
|
AC_MSG_CHECKING(for local pcap library)
|
|
|
|
lastdir=FAIL
|
|
|
|
places=`ls $srcdir/.. | sed -e 's,/$,,' -e "s,^,$srcdir/../," | \
|
2023-02-12 18:23:18 +08:00
|
|
|
$EGREP '/libpcap-[[0-9]]+\.[[0-9]]+(\.[[0-9]]*)?([[ab]][[0-9]]*|-PRE-GIT|rc.)?$'`
|
2020-07-20 11:12:32 +08:00
|
|
|
places2=`ls .. | sed -e 's,/$,,' -e "s,^,../," | \
|
2023-02-12 18:23:18 +08:00
|
|
|
$EGREP '/libpcap-[[0-9]]+\.[[0-9]]+(\.[[0-9]]*)?([[ab]][[0-9]]*|-PRE-GIT|rc.)?$'`
|
2020-07-20 11:12:32 +08:00
|
|
|
for dir in $places $srcdir/../libpcap ../libpcap $srcdir/libpcap $places2 ; do
|
|
|
|
basedir=`echo $dir | sed -e 's/[[ab]][[0-9]]*$//' | \
|
|
|
|
sed -e 's/-PRE-GIT$//' `
|
|
|
|
if test $lastdir = $basedir ; then
|
|
|
|
dnl skip alphas when an actual release is present
|
|
|
|
continue;
|
|
|
|
fi
|
|
|
|
lastdir=$dir
|
|
|
|
if test -r $dir/libpcap.a ; then
|
|
|
|
libpcap=$dir/libpcap.a
|
|
|
|
local_pcap_dir=$dir
|
|
|
|
dnl continue and select the last one that exists
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
if test $libpcap = FAIL ; then
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
#
|
2020-07-20 11:12:32 +08:00
|
|
|
# We didn't find a local libpcap.
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
#
|
2020-07-20 11:12:32 +08:00
|
|
|
AC_MSG_RESULT(not found)
|
|
|
|
using_local_libpcap=no;
|
|
|
|
else
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
#
|
2020-07-20 11:12:32 +08:00
|
|
|
# We found a local libpcap.
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
#
|
2020-07-20 11:12:32 +08:00
|
|
|
AC_MSG_RESULT($libpcap)
|
|
|
|
using_local_libpcap=yes
|
|
|
|
fi
|
|
|
|
;;
|
|
|
|
esac
|
2009-05-23 09:45:27 +08:00
|
|
|
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
if test $using_local_libpcap = no ; then
|
2017-11-14 10:55:32 +08:00
|
|
|
#
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
# We didn't find a local libpcap.
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
# Look for an installed pkg-config.
|
2017-11-14 10:55:32 +08:00
|
|
|
#
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
AC_PATH_TOOL(PKG_CONFIG, pkg-config)
|
|
|
|
if test -n "$PKG_CONFIG" ; then
|
2017-11-14 10:55:32 +08:00
|
|
|
#
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
# We have it. Are there .pc files for libpcap?
|
|
|
|
#
|
2019-04-30 15:25:37 +08:00
|
|
|
# --exists was introduced in pkg-config 0.4.0; that
|
|
|
|
# dates back to late 2000, so we won't worry about
|
|
|
|
# earlier releases that lack it.
|
|
|
|
#
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
AC_MSG_CHECKING(whether there are .pc files for libpcap)
|
|
|
|
if "$PKG_CONFIG" libpcap --exists ; then
|
|
|
|
#
|
|
|
|
# Yes, so we can use pkg-config to get configuration
|
|
|
|
# information for libpcap.
|
|
|
|
#
|
|
|
|
AC_MSG_RESULT(yes)
|
|
|
|
pkg_config_usable=yes
|
|
|
|
else
|
|
|
|
#
|
|
|
|
# No, so we can't use pkg-config to get configuration
|
|
|
|
# information for libpcap.
|
|
|
|
#
|
|
|
|
AC_MSG_RESULT(no)
|
|
|
|
pkg_config_usable=no
|
|
|
|
fi
|
|
|
|
else
|
|
|
|
#
|
|
|
|
# We don't have it, so we obviously can't use it.
|
|
|
|
#
|
|
|
|
pkg_config_usable=no
|
|
|
|
fi
|
|
|
|
if test "$pkg_config_usable" = "yes" ; then
|
|
|
|
#
|
|
|
|
# Found both - use pkg-config to get the include flags for
|
2017-11-14 10:55:32 +08:00
|
|
|
# libpcap and the flags to link with libpcap.
|
|
|
|
#
|
|
|
|
# Please read section 11.6 "Shell Substitutions"
|
|
|
|
# in the autoconf manual before doing anything
|
|
|
|
# to this that involves quoting. Especially note
|
|
|
|
# the statement "There is just no portable way to use
|
|
|
|
# double-quoted strings inside double-quoted back-quoted
|
|
|
|
# expressions (pfew!)."
|
|
|
|
#
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
cflags=`"$PKG_CONFIG" libpcap --cflags`
|
2017-11-14 10:55:32 +08:00
|
|
|
$2="$cflags $$2"
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
libpcap=`"$PKG_CONFIG" libpcap --libs`
|
2017-11-14 10:55:32 +08:00
|
|
|
else
|
|
|
|
#
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
# No pkg-config
|
|
|
|
# Look for an installed pcap-config.
|
2017-11-14 10:55:32 +08:00
|
|
|
#
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
AC_PATH_TOOL(PCAP_CONFIG, pcap-config)
|
|
|
|
if test -n "$PCAP_CONFIG" ; then
|
|
|
|
#
|
|
|
|
# Found - use it to get the include flags for
|
|
|
|
# libpcap and the flags to link with libpcap.
|
|
|
|
#
|
2021-08-08 15:36:42 +08:00
|
|
|
# If this is a vendor-supplied pcap-config, which
|
|
|
|
# we define as being "a pcap-config in /usr/bin
|
|
|
|
# or /usr/ccs/bin" (the latter is for Solaris and
|
|
|
|
# Sun/Oracle Studio), there are some issues. Work
|
|
|
|
# around them.
|
2021-08-04 03:58:34 +08:00
|
|
|
#
|
2021-08-08 15:36:42 +08:00
|
|
|
if test \( "$PCAP_CONFIG" = "/usr/bin/pcap-config" \) -o \
|
|
|
|
\( "$PCAP_CONFIG" = "/usr/ccs/bin/pcap-config" \) ; then
|
2021-08-04 03:58:34 +08:00
|
|
|
#
|
2021-08-08 15:36:42 +08:00
|
|
|
# It's vendor-supplied.
|
2021-08-04 03:58:34 +08:00
|
|
|
#
|
|
|
|
case "$host_os" in
|
|
|
|
|
|
|
|
darwin*)
|
|
|
|
#
|
|
|
|
# This is macOS or another Darwin-based OS.
|
|
|
|
#
|
|
|
|
# That means that /usr/bin/pcap-config it
|
|
|
|
# may provide -I/usr/local/include with --cflags
|
|
|
|
# and -L/usr/local/lib with --libs, rather than
|
|
|
|
# pointing to the OS-supplied library and
|
|
|
|
# Xcode-supplied headers. Remember that, so we
|
|
|
|
# ignore those values.
|
|
|
|
#
|
|
|
|
_broken_apple_pcap_config=yes
|
|
|
|
;;
|
2021-08-08 15:36:42 +08:00
|
|
|
|
|
|
|
solaris*)
|
|
|
|
#
|
|
|
|
# This is Solaris 2 or later, i.e. SunOS 5.x.
|
|
|
|
#
|
|
|
|
# At least on Solaris 11; there's /usr/bin/pcap-config,
|
|
|
|
# which reports -L/usr/lib with --libs, causing
|
|
|
|
# the 32-bit libraries to be found, and there's
|
|
|
|
# /usr/bin/{64bitarch}/pcap-config, where {64bitarch}
|
|
|
|
# is a name for the 64-bit version of the instruction
|
|
|
|
# set, which reports -L /usr/lib/{64bitarch}, causing
|
|
|
|
# the 64-bit libraries to be found.
|
|
|
|
#
|
|
|
|
# So if we're building 64-bit targets, we replace
|
|
|
|
# PCAP_CONFIG with /usr/bin/{64bitarch}; we get
|
|
|
|
# {64bitarch} as the output of "isainfo -n".
|
|
|
|
#
|
|
|
|
# Are we building 32-bit or 64-bit? Get the
|
|
|
|
# size of void *, and check that.
|
|
|
|
#
|
|
|
|
AC_CHECK_SIZEOF([void *])
|
|
|
|
if test ac_cv_sizeof_void_p -eq 8 ; then
|
|
|
|
isainfo_output=`isainfo -n`
|
|
|
|
if test ! -z "$isainfo_output" ; then
|
|
|
|
#
|
|
|
|
# Success - change PCAP_CONFIG.
|
|
|
|
#
|
|
|
|
PCAP_CONFIG=`echo $PCAP_CONFIG | sed "s;/bin/;/bin/$isainfo_output/;"`
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
;;
|
2021-08-04 03:58:34 +08:00
|
|
|
esac
|
|
|
|
fi
|
|
|
|
#
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
# Please read section 11.6 "Shell Substitutions"
|
|
|
|
# in the autoconf manual before doing anything
|
|
|
|
# to this that involves quoting. Especially note
|
|
|
|
# the statement "There is just no portable way to use
|
|
|
|
# double-quoted strings inside double-quoted back-quoted
|
|
|
|
# expressions (pfew!)."
|
|
|
|
#
|
|
|
|
cflags=`"$PCAP_CONFIG" --cflags`
|
2021-08-04 03:58:34 +08:00
|
|
|
#
|
|
|
|
# Work around macOS (and probably other Darwin) brokenness,
|
|
|
|
# by not adding /usr/local/include if it's from the broken
|
|
|
|
# Apple pcap-config.
|
|
|
|
#
|
|
|
|
if test "$_broken_apple_pcap_config" = "yes" ; then
|
|
|
|
#
|
|
|
|
# Strip -I/usr/local/include with sed.
|
|
|
|
#
|
|
|
|
cflags=`echo $cflags | sed 's;-I/usr/local/include;;'`
|
|
|
|
fi
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
$2="$cflags $$2"
|
|
|
|
libpcap=`"$PCAP_CONFIG" --libs`
|
2021-08-04 03:58:34 +08:00
|
|
|
#
|
|
|
|
# Work around macOS (and probably other Darwin) brokenness,
|
|
|
|
# by not adding /usr/local/lib if it's from the broken
|
|
|
|
# Apple pcap-config.
|
|
|
|
#
|
|
|
|
if test "$_broken_apple_pcap_config" = "yes" ; then
|
|
|
|
#
|
|
|
|
# Strip -L/usr/local/lib with sed.
|
|
|
|
#
|
|
|
|
libpcap=`echo $libpcap | sed 's;-L/usr/local/lib;;'`
|
|
|
|
fi
|
2017-11-14 10:55:32 +08:00
|
|
|
else
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
#
|
|
|
|
# Not found; look for an installed pcap.
|
|
|
|
#
|
|
|
|
AC_CHECK_LIB(pcap, main, libpcap="-lpcap")
|
|
|
|
if test $libpcap = FAIL ; then
|
2023-01-18 06:57:31 +08:00
|
|
|
AC_MSG_ERROR(see the INSTALL.md file for more info)
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
fi
|
|
|
|
dnl
|
|
|
|
dnl Some versions of Red Hat Linux put "pcap.h" in
|
|
|
|
dnl "/usr/include/pcap"; had the LBL folks done so,
|
|
|
|
dnl that would have been a good idea, but for
|
|
|
|
dnl the Red Hat folks to do so just breaks source
|
|
|
|
dnl compatibility with other systems.
|
|
|
|
dnl
|
|
|
|
dnl We work around this by assuming that, as we didn't
|
|
|
|
dnl find a local libpcap, libpcap is in /usr/lib or
|
|
|
|
dnl /usr/local/lib and that the corresponding header
|
|
|
|
dnl file is under one of those directories; if we don't
|
|
|
|
dnl find it in either of those directories, we check to
|
|
|
|
dnl see if it's in a "pcap" subdirectory of them and,
|
|
|
|
dnl if so, add that subdirectory to the "-I" list.
|
|
|
|
dnl
|
|
|
|
dnl (We now also put pcap.h in /usr/include/pcap, but we
|
|
|
|
dnl leave behind a /usr/include/pcap.h that includes it,
|
|
|
|
dnl so you can still just include <pcap.h>.)
|
|
|
|
dnl
|
|
|
|
AC_MSG_CHECKING(for extraneous pcap header directories)
|
|
|
|
if test \( ! -r /usr/local/include/pcap.h \) -a \
|
|
|
|
\( ! -r /usr/include/pcap.h \); then
|
|
|
|
if test -r /usr/local/include/pcap/pcap.h; then
|
|
|
|
d="/usr/local/include/pcap"
|
|
|
|
elif test -r /usr/include/pcap/pcap.h; then
|
|
|
|
d="/usr/include/pcap"
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
if test -z "$d" ; then
|
|
|
|
AC_MSG_RESULT(not found)
|
|
|
|
else
|
|
|
|
$2="-I$d $$2"
|
|
|
|
AC_MSG_RESULT(found -- -I$d added)
|
|
|
|
fi
|
2017-11-14 10:55:32 +08:00
|
|
|
fi
|
|
|
|
fi
|
1999-10-08 07:47:09 +08:00
|
|
|
else
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
#
|
2018-01-23 13:33:21 +08:00
|
|
|
# We found a local libpcap. Add it to the dependencies for
|
|
|
|
# tcpdump.
|
|
|
|
#
|
|
|
|
$1=$libpcap
|
|
|
|
|
|
|
|
#
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
# Look for its pcap-config script.
|
|
|
|
#
|
|
|
|
AC_PATH_PROG(PCAP_CONFIG, pcap-config,, $local_pcap_dir)
|
|
|
|
|
|
|
|
if test -n "$PCAP_CONFIG"; then
|
|
|
|
#
|
|
|
|
# We don't want its --cflags or --libs output, because
|
|
|
|
# those presume it's installed. For the C compiler flags,
|
|
|
|
# we add the source directory for the local libpcap, so
|
|
|
|
# we pick up its header files.
|
|
|
|
#
|
2017-12-01 04:59:54 +08:00
|
|
|
# We do, however, want its additional libraries, as required
|
|
|
|
# when linking statically, because it makes calls to
|
|
|
|
# routines in those libraries, so we'll need to link with
|
|
|
|
# them, because we'll be linking statically with it.
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
#
|
2022-10-01 07:29:34 +08:00
|
|
|
# If it supports --static-pcap-only. use that, as we will be
|
|
|
|
# linking with a static libpcap but won't be linking
|
|
|
|
# statically with any of the libraries on which it depends;
|
|
|
|
# those libraries might not even have static versions
|
|
|
|
# installed.
|
|
|
|
#
|
|
|
|
# That means we need to find out the libraries on which
|
|
|
|
# libpcap directly depends, so we can link with them, but we
|
|
|
|
# don't need to link with the libraries on which those
|
|
|
|
# libraries depend as, on all UN*Xes with which I'm
|
|
|
|
# familiar, the libraries on which a shared library depends
|
|
|
|
# are stored in the library and are automatically loaded by
|
|
|
|
# the run-time linker, without the executable having to be
|
|
|
|
# linked with those libraries. (This allows a library to be
|
|
|
|
# changed to depend on more libraries without breaking that
|
|
|
|
# library's ABI.)
|
|
|
|
#
|
|
|
|
# The only way to test for that support is to see if the
|
|
|
|
# script contains the string "static-pcap-only"; we can't
|
|
|
|
# try using that flag and checking for errors, as the
|
|
|
|
# versions of the script that didn't have that flag wouldn't
|
|
|
|
# report or return an error for an unsupported command-line
|
|
|
|
# flag. Those older versions provided, with --static, only
|
|
|
|
# the libraries on which libpcap depends, not the
|
|
|
|
# dependencies of those libraries; the versions with
|
|
|
|
# --static-pcap-only provide all the dependencies with
|
|
|
|
# --static, for the benefit of programs that are completely
|
|
|
|
# statically linked, and provide only the direct
|
|
|
|
# dependencies with --static-pcap-only.
|
|
|
|
#
|
2023-03-27 04:37:25 +08:00
|
|
|
if grep "static-pcap-only" "$PCAP_CONFIG" >/dev/null 2>&1
|
2022-10-01 07:29:34 +08:00
|
|
|
then
|
|
|
|
static_opt="--static-pcap-only"
|
|
|
|
else
|
|
|
|
static_opt="--static"
|
|
|
|
fi
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
$2="-I$local_pcap_dir $$2"
|
2022-10-01 07:29:34 +08:00
|
|
|
additional_libs=`"$PCAP_CONFIG" $static_opt --additional-libs`
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
libpcap="$libpcap $additional_libs"
|
2017-11-14 10:55:32 +08:00
|
|
|
else
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
#
|
|
|
|
# It doesn't have a pcap-config script.
|
|
|
|
# Make sure it has a pcap.h file.
|
|
|
|
#
|
|
|
|
places=`ls $srcdir/.. | sed -e 's,/$,,' -e "s,^,$srcdir/../," | \
|
2023-02-12 18:23:18 +08:00
|
|
|
$EGREP '/libpcap-[[0-9]]*.[[0-9]]*(.[[0-9]]*)?([[ab]][[0-9]]*)?$'`
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
places2=`ls .. | sed -e 's,/$,,' -e "s,^,../," | \
|
2023-02-12 18:23:18 +08:00
|
|
|
$EGREP '/libpcap-[[0-9]]*.[[0-9]]*(.[[0-9]]*)?([[ab]][[0-9]]*)?$'`
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
pcapH=FAIL
|
|
|
|
if test -r $local_pcap_dir/pcap.h; then
|
|
|
|
pcapH=$local_pcap_dir
|
|
|
|
else
|
|
|
|
for dir in $places $srcdir/../libpcap ../libpcap $srcdir/libpcap $places2 ; do
|
|
|
|
if test -r $dir/pcap.h ; then
|
|
|
|
pcapH=$dir
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
fi
|
|
|
|
|
|
|
|
if test $pcapH = FAIL ; then
|
2023-01-18 06:57:31 +08:00
|
|
|
AC_MSG_ERROR(cannot find pcap.h: see the INSTALL.md file)
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
fi
|
2014-09-03 09:16:24 +08:00
|
|
|
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
#
|
|
|
|
# Force the compiler to look for header files in the
|
|
|
|
# directory containing pcap.h.
|
|
|
|
#
|
|
|
|
$2="-I$pcapH $$2"
|
2017-11-14 10:55:32 +08:00
|
|
|
fi
|
2017-11-14 08:57:28 +08:00
|
|
|
fi
|
|
|
|
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
if test -z "$PKG_CONFIG" -a -z "$PCAP_CONFIG"; then
|
2017-11-14 08:57:28 +08:00
|
|
|
#
|
Use pkg-config if we can. Clean up some CMake stuff.
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.
2019-04-27 04:15:39 +08:00
|
|
|
# We don't have pkg-config or pcap-config; find out any additional
|
|
|
|
# link flags we need. (If we have pkg-config or pcap-config, we
|
|
|
|
# assume it tells us what we need.)
|
2017-11-14 08:57:28 +08:00
|
|
|
#
|
|
|
|
case "$host_os" in
|
1999-10-08 07:47:09 +08:00
|
|
|
|
2017-11-14 08:57:28 +08:00
|
|
|
aix*)
|
|
|
|
#
|
|
|
|
# If libpcap is DLPI-based, we have to use /lib/pse.exp if
|
|
|
|
# present, as we use the STREAMS routines.
|
|
|
|
#
|
|
|
|
# (XXX - true only if we're linking with a static libpcap?)
|
|
|
|
#
|
|
|
|
pseexe="/lib/pse.exp"
|
|
|
|
AC_MSG_CHECKING(for $pseexe)
|
|
|
|
if test -f $pseexe ; then
|
|
|
|
AC_MSG_RESULT(yes)
|
|
|
|
LIBS="$LIBS -I:$pseexe"
|
|
|
|
fi
|
2009-06-16 15:21:06 +08:00
|
|
|
|
2017-11-14 08:57:28 +08:00
|
|
|
#
|
|
|
|
# If libpcap is BPF-based, we need "-lodm" and "-lcfg", as
|
|
|
|
# we use them to load the BPF module.
|
|
|
|
#
|
|
|
|
# (XXX - true only if we're linking with a static libpcap?)
|
|
|
|
#
|
|
|
|
LIBS="$LIBS -lodm -lcfg"
|
|
|
|
;;
|
Fix the handling of libpcap.
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".
2017-11-30 10:18:01 +08:00
|
|
|
|
|
|
|
solaris*)
|
|
|
|
# libdlpi is needed for Solaris 11 and later.
|
|
|
|
AC_CHECK_LIB(dlpi, dlpi_walk, LIBS="$LIBS -ldlpi" LDFLAGS="-L/lib $LDFLAGS", ,-L/lib)
|
|
|
|
;;
|
2017-11-14 08:57:28 +08:00
|
|
|
esac
|
2017-11-14 10:55:32 +08:00
|
|
|
fi
|
2017-11-14 08:57:28 +08:00
|
|
|
|
|
|
|
LIBS="$libpcap $LIBS"
|
2002-12-19 17:27:54 +08:00
|
|
|
|
2010-11-15 04:23:40 +08:00
|
|
|
dnl
|
|
|
|
dnl Check for "pcap_loop()", to make sure we found a working
|
|
|
|
dnl libpcap and have all the right other libraries with which
|
|
|
|
dnl to link. (Otherwise, the checks below will fail, not
|
|
|
|
dnl because the routines are missing from the library, but
|
|
|
|
dnl because we aren't linking properly with libpcap, and
|
|
|
|
dnl that will cause confusing errors at build time.)
|
|
|
|
dnl
|
|
|
|
AC_CHECK_FUNC(pcap_loop,,
|
2017-11-14 10:55:32 +08:00
|
|
|
[
|
|
|
|
AC_MSG_ERROR(
|
2022-06-09 17:14:26 +08:00
|
|
|
[This is a bug, please follow the guidelines in CONTRIBUTING.md and include the
|
Ask for more information if we don't find pcap_loop.
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).)
2012-03-04 05:32:11 +08:00
|
|
|
config.log file in your report. If you have downloaded libpcap from
|
|
|
|
tcpdump.org, and built it yourself, please also include the config.log
|
2012-03-04 08:10:42 +08:00
|
|
|
file from the libpcap source directory, the Makefile from the libpcap
|
|
|
|
source directory, and the output of the make process for libpcap, as
|
Ask for more information if we don't find pcap_loop.
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).)
2012-03-04 05:32:11 +08:00
|
|
|
this could be a problem with the libpcap that was built, and we will
|
|
|
|
not be able to determine why this is happening, and thus will not be
|
|
|
|
able to fix it, without that information, as we have not been able to
|
|
|
|
reproduce this problem ourselves.])
|
2017-11-14 10:55:32 +08:00
|
|
|
])
|
2002-12-19 17:27:54 +08:00
|
|
|
])
|
1999-10-08 07:47:09 +08:00
|
|
|
|
|
|
|
dnl
|
2013-05-07 14:54:20 +08:00
|
|
|
dnl If the file .devel exists:
|
|
|
|
dnl Add some warning flags if the compiler supports them
|
1999-10-08 07:47:09 +08:00
|
|
|
dnl If an os prototype include exists, symlink os-proto.h to it
|
|
|
|
dnl
|
|
|
|
dnl usage:
|
|
|
|
dnl
|
|
|
|
dnl AC_LBL_DEVEL(copt)
|
|
|
|
dnl
|
|
|
|
dnl results:
|
|
|
|
dnl
|
|
|
|
dnl $1 (copt appended)
|
|
|
|
dnl HAVE_OS_PROTO_H (defined)
|
|
|
|
dnl os-proto.h (symlinked)
|
|
|
|
dnl
|
|
|
|
AC_DEFUN(AC_LBL_DEVEL,
|
|
|
|
[rm -f os-proto.h
|
|
|
|
if test "${LBL_CFLAGS+set}" = set; then
|
|
|
|
$1="$$1 ${LBL_CFLAGS}"
|
|
|
|
fi
|
|
|
|
if test -f .devel ; then
|
2013-05-08 14:58:51 +08:00
|
|
|
#
|
2013-05-13 07:10:09 +08:00
|
|
|
# Skip all the warning option stuff on some compilers.
|
2013-05-08 14:58:51 +08:00
|
|
|
#
|
2013-05-13 03:30:01 +08:00
|
|
|
if test "$ac_lbl_cc_dont_try_gcc_dashW" != yes; then
|
2018-07-08 04:01:00 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -W)
|
2013-05-08 14:58:51 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wall)
|
2018-07-08 04:01:00 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wassign-enum)
|
2015-04-27 09:50:49 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wcast-qual)
|
2018-07-08 04:01:00 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wmissing-prototypes)
|
2020-05-30 05:37:36 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wmissing-variable-declarations)
|
2023-07-28 21:03:39 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wnull-pointer-subtraction)
|
2015-09-09 13:42:39 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wold-style-definition)
|
2018-07-08 04:01:00 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wpedantic)
|
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wpointer-arith)
|
2019-07-13 17:38:48 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wpointer-sign)
|
2018-07-08 04:01:00 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wshadow)
|
2018-10-30 05:28:53 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wsign-compare)
|
2018-07-08 04:01:00 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wstrict-prototypes)
|
2024-03-07 04:21:00 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wundef)
|
2018-07-18 04:22:49 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wunreachable-code-return)
|
2023-07-28 21:03:39 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wunused-but-set-parameter)
|
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wunused-but-set-variable)
|
2016-08-19 07:19:51 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wused-but-marked-unused)
|
2018-07-08 04:01:00 +08:00
|
|
|
AC_LBL_CHECK_COMPILER_OPT($1, -Wwrite-strings)
|
2013-05-08 14:58:51 +08:00
|
|
|
fi
|
2013-05-08 15:08:12 +08:00
|
|
|
AC_LBL_CHECK_DEPENDENCY_GENERATION_OPT()
|
2023-02-12 07:36:14 +08:00
|
|
|
AC_MSG_CHECKING([whether to use an os-proto.h header])
|
2001-12-10 16:41:15 +08:00
|
|
|
os=`echo $host_os | sed -e 's/\([[0-9]][[0-9]]*\)[[^0-9]].*$/\1/'`
|
1999-10-08 07:47:09 +08:00
|
|
|
name="lbl/os-$os.h"
|
|
|
|
if test -f $name ; then
|
2023-02-12 07:36:14 +08:00
|
|
|
AC_MSG_RESULT([yes, at "$name"])
|
1999-10-08 07:47:09 +08:00
|
|
|
ln -s $name os-proto.h
|
2009-07-03 09:59:24 +08:00
|
|
|
AC_DEFINE(HAVE_OS_PROTO_H, 1,
|
2023-02-12 07:36:14 +08:00
|
|
|
[if there's an os-proto.h for this platform, to use additional prototypes])
|
1999-10-08 07:47:09 +08:00
|
|
|
else
|
2023-02-12 07:36:14 +08:00
|
|
|
AC_MSG_RESULT([no])
|
1999-10-08 07:47:09 +08:00
|
|
|
fi
|
|
|
|
fi])
|
|
|
|
|
|
|
|
dnl
|
2024-02-03 06:24:41 +08:00
|
|
|
dnl This is a simplified adaptation of AC_LBL_LIBRARY_NET from libpcap.
|
|
|
|
dnl In this context tcpdump needs gethostbyaddr() only.
|
1999-10-08 07:47:09 +08:00
|
|
|
dnl
|
|
|
|
AC_DEFUN(AC_LBL_LIBRARY_NET, [
|
2024-02-03 06:24:41 +08:00
|
|
|
AC_CHECK_FUNC(gethostbyaddr,,
|
|
|
|
[
|
2023-01-14 19:21:06 +08:00
|
|
|
AC_CHECK_LIB(socket, gethostbyaddr,
|
2024-02-03 06:24:41 +08:00
|
|
|
[
|
|
|
|
LIBS="-lsocket -lnsl $LIBS"
|
|
|
|
],
|
|
|
|
[
|
|
|
|
AC_CHECK_LIB(network, gethostbyaddr,
|
|
|
|
[
|
|
|
|
LIBS="-lnetwork $LIBS"
|
|
|
|
],
|
|
|
|
[
|
|
|
|
AC_MSG_ERROR([gethostbyaddr is required, but wasn't found])
|
|
|
|
])
|
|
|
|
], -lnsl)
|
1999-10-08 07:47:09 +08:00
|
|
|
])
|
2024-02-03 06:24:41 +08:00
|
|
|
])
|