mirrors/tcpdump
0
0
Fork 0
mirror of https://github.com/the-tcpdump-group/tcpdump.git synced 2024-11-27 12:03:44 +08:00
Code Issues Packages Projects Releases Wiki Activity
780f86b43c
tcpdump/aclocal.m4

1175 lines
39 KiB
Plaintext
Raw Normal View History

Initial revision
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
Fix some problems that show up in autoconf 2.64 and later.
2010-01-03 07:29:06 +08:00
dnl Do whatever AC_LBL_C_INIT work is necessary before using AC_PROG_CC.
Initial revision
1999-10-08 07:47:09 +08:00
dnl
Fix some problems that show up in autoconf 2.64 and later.
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.
Initial revision
1999-10-08 07:47:09 +08:00
dnl
Fix some problems that show up in autoconf 2.64 and later.
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.
Initial revision
1999-10-08 07:47:09 +08:00
dnl
Fix some problems that show up in autoconf 2.64 and later.
2010-01-03 07:29:06 +08:00
AC_DEFUN(AC_LBL_C_INIT_BEFORE_CC,
We require autoconf 2.61 in configure.in; that suffices. Don't say "we require 2.50" in various macros.
2013-10-18 08:00:38 +08:00
[
Fix some problems that show up in autoconf 2.64 and later.
2010-01-03 07:29:06 +08:00
AC_BEFORE([$0], [AC_LBL_C_INIT])
Initial revision
1999-10-08 07:47:09 +08:00
AC_BEFORE([$0], [AC_PROG_CC])
AC_BEFORE([$0], [AC_LBL_FIXINCLUDES])
AC_BEFORE([$0], [AC_LBL_DEVEL])
AC_ARG_WITH(gcc, [ --without-gcc don't use gcc])
Clean up handling of -g and -O flags. 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.
2013-10-18 07:50:43 +08:00
$1=""
Initial revision
1999-10-08 07:47:09 +08:00
if test "${srcdir}" != "." ; then
Clean up handling of -g and -O flags. 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.
2013-10-18 07:50:43 +08:00
$1="-I$srcdir"
Initial revision
1999-10-08 07:47:09 +08:00
fi
if test "${CFLAGS+set}" = set; then
LBL_CFLAGS="$CFLAGS"
fi
if test -z "$CC" ; then
Replace "target_cpu", "target_os", and AC_CANONICAL_SYSTEM with "host_cpu", "host_os", and AC_CANONICAL_HOST, as per Maciej W. Rozycki's patch.
2001-12-10 16:41:15 +08:00
case "$host_os" in
Initial revision
1999-10-08 07:47:09 +08:00
bsdi*)
AC_CHECK_PROG(SHLICC2, shlicc2, yes, no)
if test $SHLICC2 = yes ; then
CC=shlicc2
export CC
fi
;;
esac
fi
if test -z "$CC" -a "$with_gcc" = no ; then
CC=cc
export CC
fi
Fix some problems that show up in autoconf 2.64 and later.
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
Clean up handling of -g and -O flags. 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.
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)
Add -g3 on some platforms even if .devel isn't present. 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.
2013-10-22 01:56:33 +08:00
dnl add -g flags, as appropriate
Clean up handling of -g and -O flags. 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.
2013-10-18 07:50:43 +08:00
dnl explicitly specify /usr/local/include
Fix some problems that show up in autoconf 2.64 and later.
2010-01-03 07:29:06 +08:00
dnl
Note that clang, for example, is considered "gcc" by autoconf.
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
Fix some problems that show up in autoconf 2.64 and later.
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,
We require autoconf 2.61 in configure.in; that suffices. Don't say "we require 2.50" in various macros.
2013-10-18 08:00:38 +08:00
[
Fix some problems that show up in autoconf 2.64 and later.
2010-01-03 07:29:06 +08:00
AC_BEFORE([$0], [AC_LBL_FIXINCLUDES])
AC_BEFORE([$0], [AC_LBL_DEVEL])
AC_BEFORE([$0], [AC_LBL_SHLIBS_INIT])
Initial revision
1999-10-08 07:47:09 +08:00
if test "$GCC" = yes ; then
Avoid some warnings from Sun C. 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.
2013-06-23 05:06:33 +08:00
#
# -Werror forces warnings to be errors.
#
ac_lbl_cc_force_warning_errors=-Werror
Initial revision
1999-10-08 07:47:09 +08:00
else
$2="$$2 -I/usr/local/include"
LDFLAGS="$LDFLAGS -L/usr/local/lib"
Replace "target_cpu", "target_os", and AC_CANONICAL_SYSTEM with "host_cpu", "host_os", and AC_CANONICAL_HOST, as per Maciej W. Rozycki's patch.
2001-12-10 16:41:15 +08:00
case "$host_os" in
Initial revision
1999-10-08 07:47:09 +08:00
Avoid some warnings from Sun C. 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.
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.
#
ac_lbl_cc_force_warning_errors=-Werror
;;
Don't try -W flags with HP's C compiler. 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.
2013-05-08 14:58:51 +08:00
hpux*)
#
HP C isn't the only compiler on which we must avoid GCC-style -W flags. 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.
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.
Don't try -W flags with HP's C compiler. 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.
2013-05-08 14:58:51 +08:00
#
HP C isn't the only compiler on which we must avoid GCC-style -W flags. 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.
2013-05-13 03:30:01 +08:00
ac_lbl_cc_dont_try_gcc_dashW=yes
Don't try -W flags with HP's C compiler. 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.
2013-05-08 14:58:51 +08:00
;;
Initial revision
1999-10-08 07:47:09 +08:00
irix*)
HP C isn't the only compiler on which we must avoid GCC-style -W flags. 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.
2013-05-13 03:30:01 +08:00
#
# MIPS C, which is what we presume we're using, doesn't
# necessarily exit with a non-zero exit status if we
# hand it an invalid -W flag, can't be forced to do
# so, and doesn't handle GCC-style -W flags, so we
# don't want to try using GCC-style -W flags.
#
ac_lbl_cc_dont_try_gcc_dashW=yes
Explain why we set -xansi -signed for MIPS C.
2013-10-18 13:14:53 +08:00
#
# It also, apparently, defaults to "char" being
# unsigned, unlike most other C implementations;
# I suppose we could say "signed char" whenever
# we want to guarantee a signed "char", but let's
# just force signed chars.
#
# -xansi is normally the default, but the
# configure script was setting it; perhaps -cckr
# was the default in the Old Days. (Then again,
# that would probably be for backwards compatibility
# in the days when ANSI C was Shiny and New, i.e.
# 1989 and the early '90's, so maybe we can just
# drop support for those compilers.)
#
Add -g3 on some platforms even if .devel isn't present. 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.
2013-10-22 01:56:33 +08:00
# -g is equivalent to -g2, which turns off
# optimization; we choose -g3, which generates
# debugging information but doesn't turn off
# optimization (even if the optimization would
# cause inaccuracies in debugging).
#
$1="$$1 -xansi -signed -g3"
Initial revision
1999-10-08 07:47:09 +08:00
;;
osf*)
Fix spaces
2018-09-03 20:03:25 +08:00
#
Pick up some AC_DEFINE comments from libpcap's aclocal.m4. Remove unused items, and items for which we now have AC_DEFINE() calls that supply a comment, from acconfig.h. Note that a host OS that matches "osf*" is assumed to be DEC OSF1/Digital UNIX/Tru64 UNIX.
2009-07-03 09:59:24 +08:00
# Presumed to be DEC OSF/1, Digital UNIX, or
# Tru64 UNIX.
#
HP C isn't the only compiler on which we must avoid GCC-style -W flags. 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.
2013-05-13 03:30:01 +08:00
# The DEC C compiler, 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, and doesn't handle GCC-style -W flags, so we
# don't want to try using GCC-style -W flags.
#
ac_lbl_cc_dont_try_gcc_dashW=yes
Add -g3 on some platforms even if .devel isn't present. 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.
2013-10-22 01:56:33 +08:00
#
# -g is equivalent to -g2, which turns off
# optimization; we choose -g3, which generates
# debugging information but doesn't turn off
# optimization (even if the optimization would
# cause inaccuracies in debugging).
#
$1="$$1 -g3"
Initial revision
1999-10-08 07:47:09 +08:00
;;
Avoid some warnings from Sun C. 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.
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
;;
Initial revision
1999-10-08 07:47:09 +08:00
ultrix*)
AC_MSG_CHECKING(that Ultrix $CC hacks const in prototypes)
AC_CACHE_VAL(ac_cv_lbl_cc_const_proto,
AC_TRY_COMPILE(
[#include <sys/types.h>],
[struct a { int b; };
void c(const struct a *)],
ac_cv_lbl_cc_const_proto=yes,
ac_cv_lbl_cc_const_proto=no))
AC_MSG_RESULT($ac_cv_lbl_cc_const_proto)
if test $ac_cv_lbl_cc_const_proto = no ; then
Add a comment to the AC_DEFINE call for const, just as we did for libpcap; that eliminates the need to list it in acconfig.h, so get rid of that.
2009-07-03 10:28:34 +08:00
AC_DEFINE(const,[],
[to handle Ultrix compilers that don't support const in prototypes])
Initial revision
1999-10-08 07:47:09 +08:00
fi
;;
esac
Clean up handling of -g and -O flags. 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.
2013-10-18 07:50:43 +08:00
$1="$$1 -O"
Initial revision
1999-10-08 07:47:09 +08:00
fi
])
With .devel, use -W flags iff the compiler supports 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).
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
#
configure: use AC_COMPILE_IFELSE() and AC_LANG_SOURCE() for testing flags. 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.
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
#
configure: use AC_COMPILE_IFELSE() and AC_LANG_SOURCE() for testing flags. 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.
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
#
configure: use AC_COMPILE_IFELSE() and AC_LANG_SOURCE() for testing flags. 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.
2021-07-25 18:02:54 +08:00
# This may, as per those two messages, be fixed in autoonf 2.70,
# but we only require 2.64 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
#
configure: use AC_COMPILE_IFELSE() and AC_LANG_SOURCE() for testing flags. 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.
2021-07-25 18:02:54 +08:00
AC_COMPILE_IFELSE(
[AC_LANG_SOURCE([[int main(void) { return 0; }]])],
With .devel, use -W flags iff the compiler supports 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).
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"
With .devel, use -W flags iff the compiler supports 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).
2013-05-07 14:54:20 +08:00
])
Support dependency generation with some non-GCC compilers. Also, if we don't support it with a given compiler, have "make depend" not run mkdep, as it won't do anything useful.
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
irix*|osf*|darwin*)
#
# MIPS C for IRIX, DEC C, and clang all use -M.
#
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; }]])])
Use AC_RUN_LOG when testing the dependency-generating flag.
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
Support dependency generation with some non-GCC compilers. Also, if we don't support it with a given compiler, have "make depend" not run mkdep, as it won't do anything useful.
2013-05-08 15:08:12 +08:00
AC_MSG_RESULT([yes, with $ac_lbl_dependency_flag])
DEPENDENCY_CFLAG="$ac_lbl_dependency_flag"
Look for mkdep in the top-level source directory. Not currently a problem for tcpdump, as we have no subdirectories, but this will leave us prepared for subdirectories if we ever add any.
2020-03-03 08:15:07 +08:00
MKDEP='${top_srcdir}/mkdep'
Support dependency generation with some non-GCC compilers. Also, if we don't support it with a given compiler, have "make depend" not run mkdep, as it won't do anything useful.
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
AC_SUBST doesn't take a list of macros to substitute.
2013-05-13 07:37:47 +08:00
AC_SUBST(DEPENDENCY_CFLAG)
AC_SUBST(MKDEP)
Support dependency generation with some non-GCC compilers. Also, if we don't support it with a given compiler, have "make depend" not run mkdep, as it won't do anything useful.
2013-05-08 15:08:12 +08:00
])
Put back AC_LBL_C_INLINE; it turns out that wasn't the cause of the inline problem, and AC_LBL_C_INLINE checks for a case that some versions of the HP C compiler don't handle, and only uses inline if that case succeeds.
2005-04-21 10:21:47 +08:00
#
# Try compiling a sample of the type of code that appears in
# gencode.c with "inline", "__inline__", and "__inline".
#
# Autoconf's AC_C_INLINE, at least in autoconf 2.13, isn't good enough,
# as it just tests whether a function returning "int" can be inlined;
# at least some versions of HP's C compiler can inline that, but can't
# inline a function that returns a struct pointer.
#
As with libpcap, so with tcpdump; when testing whether "inline" works, use the V_CCOPT flags, because some of those might disable inlining; otherwise, the test for inlining will succeed, but inlining won't work with the options we're using when compiling.
2009-07-03 02:55:00 +08:00
# Make sure we use the V_CCOPT flags, because some of those might
# disable inlining.
#
Put back AC_LBL_C_INLINE; it turns out that wasn't the cause of the inline problem, and AC_LBL_C_INLINE checks for a case that some versions of the HP C compiler don't handle, and only uses inline if that case succeeds.
2005-04-21 10:21:47 +08:00
AC_DEFUN(AC_LBL_C_INLINE,
[AC_MSG_CHECKING(for inline)
As with libpcap, so with tcpdump; when testing whether "inline" works, use the V_CCOPT flags, because some of those might disable inlining; otherwise, the test for inlining will succeed, but inlining won't work with the options we're using when compiling.
2009-07-03 02:55:00 +08:00
save_CFLAGS="$CFLAGS"
CFLAGS="$V_CCOPT"
Put back AC_LBL_C_INLINE; it turns out that wasn't the cause of the inline problem, and AC_LBL_C_INLINE checks for a case that some versions of the HP C compiler don't handle, and only uses inline if that case succeeds.
2005-04-21 10:21:47 +08:00
AC_CACHE_VAL(ac_cv_lbl_inline, [
ac_cv_lbl_inline=""
ac_lbl_cc_inline=no
for ac_lbl_inline in inline __inline__ __inline
do
AC_TRY_COMPILE(
[#define inline $ac_lbl_inline
static inline struct iltest *foo(void);
struct iltest {
int iltest1;
int iltest2;
};
static inline struct iltest *
foo()
{
static struct iltest xxx;
return &xxx;
}],,ac_lbl_cc_inline=yes,)
if test "$ac_lbl_cc_inline" = yes ; then
break;
fi
done
if test "$ac_lbl_cc_inline" = yes ; then
ac_cv_lbl_inline=$ac_lbl_inline
fi])
As with libpcap, so with tcpdump; when testing whether "inline" works, use the V_CCOPT flags, because some of those might disable inlining; otherwise, the test for inlining will succeed, but inlining won't work with the options we're using when compiling.
2009-07-03 02:55:00 +08:00
CFLAGS="$save_CFLAGS"
Put back AC_LBL_C_INLINE; it turns out that wasn't the cause of the inline problem, and AC_LBL_C_INLINE checks for a case that some versions of the HP C compiler don't handle, and only uses inline if that case succeeds.
2005-04-21 10:21:47 +08:00
if test ! -z "$ac_cv_lbl_inline" ; then
AC_MSG_RESULT($ac_cv_lbl_inline)
else
AC_MSG_RESULT(no)
fi
AC_DEFINE_UNQUOTED(inline, $ac_cv_lbl_inline, [Define as token for inline if inlining supported])])
Initial revision
1999-10-08 07:47:09 +08:00
dnl
dnl Use pfopen.c if available and pfopen() not in standard libraries
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.
Initial revision
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 LBL_LIBS
dnl
AC_DEFUN(AC_LBL_LIBPCAP,
[AC_REQUIRE([AC_LBL_LIBRARY_NET])
dnl
dnl save a copy before locating libpcap.a
dnl
LBL_LIBS="$LIBS"
pfopen=/usr/examples/packetfilter/pfopen.c
if test -f $pfopen ; then
Clean up indentation.
2017-11-14 10:55:32 +08:00
AC_CHECK_FUNCS(pfopen)
if test $ac_cv_func_pfopen = "no" ; then
AC_MSG_RESULT(Using $pfopen)
LIBS="$LIBS $pfopen"
fi
fi
libpcap=FAIL
autoconf: replace --with-system-libpcap with --disable-local-libpcap. --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.
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
;;
Remove a trailing tab
2020-08-01 18:04:52 +08:00
autoconf: replace --with-system-libpcap with --disable-local-libpcap. --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.
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/../," | \
autoconf: Find a local libpcap even with rcX directory suffix
2021-06-08 03:01:15 +08:00
egrep '/libpcap-[[0-9]]+\.[[0-9]]+(\.[[0-9]]*)?([[ab]][[0-9]]*|-PRE-GIT|rc.)?$'`
autoconf: replace --with-system-libpcap with --disable-local-libpcap. --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.
2020-07-20 11:12:32 +08:00
places2=`ls .. | sed -e 's,/$,,' -e "s,^,../," | \
autoconf: Find a local libpcap even with rcX directory suffix
2021-06-08 03:01:15 +08:00
egrep '/libpcap-[[0-9]]+\.[[0-9]]+(\.[[0-9]]*)?([[ab]][[0-9]]*|-PRE-GIT|rc.)?$'`
autoconf: replace --with-system-libpcap with --disable-local-libpcap. --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.
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
#
autoconf: replace --with-system-libpcap with --disable-local-libpcap. --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.
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
#
autoconf: replace --with-system-libpcap with --disable-local-libpcap. --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.
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
#
autoconf: replace --with-system-libpcap with --disable-local-libpcap. --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.
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
#
autoconf: replace --with-system-libpcap with --disable-local-libpcap. --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.
2020-07-20 11:12:32 +08:00
AC_MSG_RESULT($libpcap)
using_local_libpcap=yes
fi
;;
esac
If we're using a local libpcap library, check for a local pcap-config script and, if we find it, query it to see what additional libraries are needed to link with that library. If we're not, check for a system pcap-config script and, if we find it, query it to see what C compiler flags and linker flags are needed to build with that library.
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
Clean up indentation.
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.
Clean up indentation.
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
Clean up indentation.
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?
#
Note that we don't need to worry about pkg-config lacking --exists. [skip ci]
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
Clean up indentation.
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`
Clean up indentation.
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`
Clean up indentation.
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.
Clean up indentation.
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.
#
configure: special-case macOS /usr/bin/pcap-config as we do in CMake. 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.
2021-08-04 03:58:34 +08:00
# If this is a system-supplied pcap-config, which
# we define as being "a pcap-config in /usr/bin",
# there are some issues. Work around them.
#
if test "$PCAP_CONFIG" = "/usr/bin/pcap-config" ; then
#
# It's /usr/bin/pcap-config.
#
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
;;
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`
configure: special-case macOS /usr/bin/pcap-config as we do in CMake. 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.
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`
configure: special-case macOS /usr/bin/pcap-config as we do in CMake. 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.
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
Clean up indentation.
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
AC_MSG_ERROR(see the INSTALL doc for more info)
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
Clean up indentation.
2017-11-14 10:55:32 +08:00
fi
fi
Initial revision
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
#
If we have a local libpcap, add it to the dependencies for tcpdump. We weren't doing so if we found a local pcap-config script.
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.
#
Fix typo, and request additional libraries for *static* linking.
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
#
$2="-I$local_pcap_dir $$2"
Fix typo, and request additional libraries for *static* linking.
2017-12-01 04:59:54 +08:00
additional_libs=`"$PCAP_CONFIG" --static --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"
Clean up indentation.
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/../," | \
egrep '/libpcap-[[0-9]]*.[[0-9]]*(.[[0-9]]*)?([[ab]][[0-9]]*)?$'`
places2=`ls .. | sed -e 's,/$,,' -e "s,^,../," | \
egrep '/libpcap-[[0-9]]*.[[0-9]]*(.[[0-9]]*)?([[ab]][[0-9]]*)?$'`
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
AC_MSG_ERROR(cannot find pcap.h: see INSTALL)
fi
these changes to aclocal let tcpdump, when build out of source tree, to find a libpcap that is adjacent to it, also built out of source tree
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"
Clean up indentation.
2017-11-14 10:55:32 +08:00
fi
Some tweaks for AC_LBL_LIBPCAP
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
Some tweaks for AC_LBL_LIBPCAP
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.)
Some tweaks for AC_LBL_LIBPCAP
2017-11-14 08:57:28 +08:00
#
case "$host_os" in
Initial revision
1999-10-08 07:47:09 +08:00
Some tweaks for AC_LBL_LIBPCAP
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
On AIX, if we have pcap-config, rely on it to supply the right extra flags for linking with libpcap.
2009-06-16 15:21:06 +08:00
Some tweaks for AC_LBL_LIBPCAP
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)
;;
Some tweaks for AC_LBL_LIBPCAP
2017-11-14 08:57:28 +08:00
esac
Clean up indentation.
2017-11-14 10:55:32 +08:00
fi
Some tweaks for AC_LBL_LIBPCAP
2017-11-14 08:57:28 +08:00
LIBS="$libpcap $LIBS"
NetBSD support for multiple data link types on an interface, from David Young <dyoung@ojctech.com>, with some minor changes by Jason R. Thorpe <thorpej@netbsd.org>, and further changes by me to: use "-y" rather than "-D" to set the link type ("-D" was already taken); use libpcap APIs to map between data link type names and values; supply stub versions of missing-but-needed libpcap APIs. Update Jason Thorpe's e-mail address (Zembu is going away, if it hasn't done so already).
2002-12-19 17:27:54 +08:00
Make sure we can link with libpcap. 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.)
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,,
Clean up indentation.
2017-11-14 10:55:32 +08:00
[
AC_MSG_ERROR(
refine the feedback guidelines Provide better detailed guidelines in CONTRIBUTING and update a number of other files to refer to that file so that the directions are now more uniform.
2017-02-02 19:23:50 +08:00
[This is a bug, please follow the guidelines in CONTRIBUTING 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
Ask for the libpcap Makefile while we're at it. ...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.
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.])
Clean up indentation.
2017-11-14 10:55:32 +08:00
])
NetBSD support for multiple data link types on an interface, from David Young <dyoung@ojctech.com>, with some minor changes by Jason R. Thorpe <thorpej@netbsd.org>, and further changes by me to: use "-y" rather than "-D" to set the link type ("-D" was already taken); use libpcap APIs to map between data link type names and values; supply stub versions of missing-but-needed libpcap APIs. Update Jason Thorpe's e-mail address (Zembu is going away, if it hasn't done so already).
2002-12-19 17:27:54 +08:00
])
Initial revision
1999-10-08 07:47:09 +08:00
dnl
dnl If using gcc, make sure we have ANSI ioctl definitions
dnl
dnl usage:
dnl
dnl AC_LBL_FIXINCLUDES
dnl
AC_DEFUN(AC_LBL_FIXINCLUDES,
[if test "$GCC" = yes ; then
AC_MSG_CHECKING(for ANSI ioctl definitions)
AC_CACHE_VAL(ac_cv_lbl_gcc_fixincludes,
AC_TRY_COMPILE(
[/*
* This generates a "duplicate case value" when fixincludes
* has not be run.
*/
# include <sys/types.h>
# include <sys/time.h>
# include <sys/ioctl.h>
# ifdef HAVE_SYS_IOCCOM_H
# include <sys/ioccom.h>
# endif],
[switch (0) {
case _IO('A', 1):;
case _IO('B', 1):;
}],
ac_cv_lbl_gcc_fixincludes=yes,
ac_cv_lbl_gcc_fixincludes=no))
AC_MSG_RESULT($ac_cv_lbl_gcc_fixincludes)
if test $ac_cv_lbl_gcc_fixincludes = no ; then
# Don't cache failure
unset ac_cv_lbl_gcc_fixincludes
AC_MSG_ERROR(see the INSTALL for more info)
fi
fi])
dnl
dnl Checks to see if union wait is used with WEXITSTATUS()
dnl
dnl usage:
dnl
dnl AC_LBL_UNION_WAIT
dnl
dnl results:
dnl
dnl DECLWAITSTATUS (defined)
dnl
AC_DEFUN(AC_LBL_UNION_WAIT,
[AC_MSG_CHECKING(if union wait is used)
AC_CACHE_VAL(ac_cv_lbl_union_wait,
AC_TRY_COMPILE([
# include <sys/types.h>
# include <sys/wait.h>],
[int status;
u_int i = WEXITSTATUS(status);
u_int j = waitpid(0, &status, 0);],
ac_cv_lbl_union_wait=no,
ac_cv_lbl_union_wait=yes))
AC_MSG_RESULT($ac_cv_lbl_union_wait)
if test $ac_cv_lbl_union_wait = yes ; then
Pick up some AC_DEFINE comments from libpcap's aclocal.m4. Remove unused items, and items for which we now have AC_DEFINE() calls that supply a comment, from acconfig.h. Note that a host OS that matches "osf*" is assumed to be DEC OSF1/Digital UNIX/Tru64 UNIX.
2009-07-03 09:59:24 +08:00
AC_DEFINE(DECLWAITSTATUS,union wait,[type for wait])
Initial revision
1999-10-08 07:47:09 +08:00
else
Pick up some AC_DEFINE comments from libpcap's aclocal.m4. Remove unused items, and items for which we now have AC_DEFINE() calls that supply a comment, from acconfig.h. Note that a host OS that matches "osf*" is assumed to be DEC OSF1/Digital UNIX/Tru64 UNIX.
2009-07-03 09:59:24 +08:00
AC_DEFINE(DECLWAITSTATUS,int,[type for wait])
Initial revision
1999-10-08 07:47:09 +08:00
fi])
dnl
dnl Checks to see if -R is used
dnl
dnl usage:
dnl
dnl AC_LBL_HAVE_RUN_PATH
dnl
dnl results:
dnl
dnl ac_cv_lbl_have_run_path (yes or no)
dnl
AC_DEFUN(AC_LBL_HAVE_RUN_PATH,
[AC_MSG_CHECKING(for ${CC-cc} -R)
AC_CACHE_VAL(ac_cv_lbl_have_run_path,
[echo 'main(){}' > conftest.c
${CC-cc} -o conftest conftest.c -R/a1/b2/c3 >conftest.out 2>&1
if test ! -s conftest.out ; then
ac_cv_lbl_have_run_path=yes
else
ac_cv_lbl_have_run_path=no
fi
When removing conftest*, use "-r", to clean up OS X .dSYM turds.
2010-01-03 07:59:43 +08:00
rm -f -r conftest*])
Initial revision
1999-10-08 07:47:09 +08:00
AC_MSG_RESULT($ac_cv_lbl_have_run_path)
])
Second stage of adding support for 64-bit integral data types - this causes the configure script to attempt to define the PRI[doux]64 macros if they're not defined by including <inttypes.h>, and causes "missing/bittypes.h" to attempt to define them, if undefined, in a fashion that should, with any luck, work on MSVC++ and various flavors of GNU C on Windows. Fix the spelling of "Mac OS X".
2004-04-17 16:44:49 +08:00
dnl
dnl Check whether a given format can be used to print 64-bit integers
dnl
AC_DEFUN(AC_LBL_CHECK_64BIT_FORMAT,
[
AC_MSG_CHECKING([whether %$1x can be used to format 64-bit integers])
AC_RUN_IFELSE(
[
AC_LANG_SOURCE(
[[
# ifdef HAVE_INTTYPES_H
#include <inttypes.h>
# endif
#include <stdio.h>
#include <sys/types.h>
main()
{
u_intN_t is dead, long live uintN_t. And, as we require at least autoconf 2.61, and as autoconf 2.61 and later have AC_TYPE_UINTn_T and AC_TYPE_INTn_T macros, we use them to define the uintN_t and intN_t macros if the system doesn't define them for us. This lets us get rid of bitypes.h as well.
2014-04-23 15:20:40 +08:00
uint64_t t = 1;
Second stage of adding support for 64-bit integral data types - this causes the configure script to attempt to define the PRI[doux]64 macros if they're not defined by including <inttypes.h>, and causes "missing/bittypes.h" to attempt to define them, if undefined, in a fashion that should, with any luck, work on MSVC++ and various flavors of GNU C on Windows. Fix the spelling of "Mac OS X".
2004-04-17 16:44:49 +08:00
char strbuf[16+1];
sprintf(strbuf, "%016$1x", t << 32);
if (strcmp(strbuf, "0000000100000000") == 0)
exit(0);
else
exit(1);
}
]])
],
[
Get rid of acconfig.h.
2013-05-13 06:28:28 +08:00
AC_DEFINE(PRId64, "$1d", [define if the platform doesn't define PRId64])
AC_DEFINE(PRIo64, "$1o", [define if the platform doesn't define PRIo64])
AC_DEFINE(PRIx64, "$1x", [define if the platform doesn't define PRIu64])
AC_DEFINE(PRIu64, "$1u", [define if the platform doesn't define PRIx64])
Second stage of adding support for 64-bit integral data types - this causes the configure script to attempt to define the PRI[doux]64 macros if they're not defined by including <inttypes.h>, and causes "missing/bittypes.h" to attempt to define them, if undefined, in a fashion that should, with any luck, work on MSVC++ and various flavors of GNU C on Windows. Fix the spelling of "Mac OS X".
2004-04-17 16:44:49 +08:00
AC_MSG_RESULT(yes)
],
[
AC_MSG_RESULT(no)
$2
])
])
Initial revision
1999-10-08 07:47:09 +08:00
dnl
With .devel, use -W flags iff the compiler supports 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).
2013-05-07 14:54:20 +08:00
dnl If the file .devel exists:
dnl Add some warning flags if the compiler supports them
Initial revision
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
Don't try -W flags with HP's C compiler. 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.
2013-05-08 14:58:51 +08:00
#
Update a comment.
2013-05-13 07:10:09 +08:00
# Skip all the warning option stuff on some compilers.
Don't try -W flags with HP's C compiler. 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.
2013-05-08 14:58:51 +08:00
#
HP C isn't the only compiler on which we must avoid GCC-style -W flags. 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.
2013-05-13 03:30:01 +08:00
if test "$ac_lbl_cc_dont_try_gcc_dashW" != yes; then
Sort the tested compiler warning options
2018-07-08 04:01:00 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -W)
Don't try -W flags with HP's C compiler. 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.
2013-05-08 14:58:51 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wall)
Sort the tested compiler warning options
2018-07-08 04:01:00 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wassign-enum)
Compile with -Wcast-qual. That let me find what might have been the bulk of the 579(!) instances of "Deconst" reported in http://www.cl.cam.ac.uk/~dc552/papers/asplos15-memory-safe-c.pdf and, hopefully, will prevent more from creeping in. There are some remaining ones - and they represent attempts to overwrite the packet bytes handed to tcpdump by libpcap, which could well *fail* with, for example, memory-mapped capture mechanisms!
2015-04-27 09:50:49 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wcast-qual)
Sort the tested compiler warning options
2018-07-08 04:01:00 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wmissing-prototypes)
Compile with '-Wmissing-variable-declarations' if it's available (In devel mode)
2020-05-30 05:37:36 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wmissing-variable-declarations)
Compile with '-Wold-style-definition' in devel mode
2015-09-09 13:42:39 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wold-style-definition)
Sort the tested compiler warning options
2018-07-08 04:01:00 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wpedantic)
AC_LBL_CHECK_COMPILER_OPT($1, -Wpointer-arith)
Use -Wpointer-sign if it's available
2019-07-13 17:38:48 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wpointer-sign)
Sort the tested compiler warning options
2018-07-08 04:01:00 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wshadow)
Compile with '-Wsign-compare' in devel mode if supported
2018-10-30 05:28:53 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wsign-compare)
Sort the tested compiler warning options
2018-07-08 04:01:00 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wstrict-prototypes)
Compile with '-Wunreachable-code-return' in devel mode if supported
2018-07-18 04:22:49 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wunreachable-code-return)
Compile with '-Wused-but-marked-unused' in devel mode if supported f.e. clang version 3.4 support this warning option.
2016-08-19 07:19:51 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wused-but-marked-unused)
Sort the tested compiler warning options
2018-07-08 04:01:00 +08:00
AC_LBL_CHECK_COMPILER_OPT($1, -Wwrite-strings)
Don't try -W flags with HP's C compiler. 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.
2013-05-08 14:58:51 +08:00
fi
Support dependency generation with some non-GCC compilers. Also, if we don't support it with a given compiler, have "make depend" not run mkdep, as it won't do anything useful.
2013-05-08 15:08:12 +08:00
AC_LBL_CHECK_DEPENDENCY_GENERATION_OPT()
Add -g3 on some platforms even if .devel isn't present. 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.
2013-10-22 01:56:33 +08:00
#
# We used to set -n32 for IRIX 6 when not using GCC (presumed
# to mean that we're using MIPS C or MIPSpro C); it specified
# the "new" faster 32-bit ABI, introduced in IRIX 6.2. I'm
# not sure why that would be something to do *only* with a
# .devel file; why should the ABI for which we produce code
# depend on .devel?
#
Replace "target_cpu", "target_os", and AC_CANONICAL_SYSTEM with "host_cpu", "host_os", and AC_CANONICAL_HOST, as per Maciej W. Rozycki's patch.
2001-12-10 16:41:15 +08:00
os=`echo $host_os | sed -e 's/\([[0-9]][[0-9]]*\)[[^0-9]].*$/\1/'`
Initial revision
1999-10-08 07:47:09 +08:00
name="lbl/os-$os.h"
if test -f $name ; then
ln -s $name os-proto.h
Pick up some AC_DEFINE comments from libpcap's aclocal.m4. Remove unused items, and items for which we now have AC_DEFINE() calls that supply a comment, from acconfig.h. Note that a host OS that matches "osf*" is assumed to be DEC OSF1/Digital UNIX/Tru64 UNIX.
2009-07-03 09:59:24 +08:00
AC_DEFINE(HAVE_OS_PROTO_H, 1,
[if there's an os_proto.h for this platform, to use additional prototypes])
Initial revision
1999-10-08 07:47:09 +08:00
else
AC_MSG_WARN(can't find $name)
fi
fi])
dnl
dnl Improved version of AC_CHECK_LIB
dnl
dnl Thanks to John Hawkinson (jhawk@mit.edu)
dnl
dnl usage:
dnl
dnl AC_LBL_CHECK_LIB(LIBRARY, FUNCTION [, ACTION-IF-FOUND [,
dnl ACTION-IF-NOT-FOUND [, OTHER-LIBRARIES]]])
dnl
dnl results:
dnl
dnl LIBS
dnl
Explain why "AC_LBL_CHECK_LIB" isn't used any more.
2002-08-05 05:20:29 +08:00
dnl XXX - "AC_LBL_LIBRARY_NET" was redone to use "AC_SEARCH_LIBS"
dnl rather than "AC_LBL_CHECK_LIB", so this isn't used any more.
dnl We keep it around for reference purposes in case it's ever
dnl useful in the future.
Note that "AC_LBL_CHECK_LIB" isn't used any more.
2002-08-04 06:32:36 +08:00
dnl
Initial revision
1999-10-08 07:47:09 +08:00
define(AC_LBL_CHECK_LIB,
[AC_MSG_CHECKING([for $2 in -l$1])
Don't include <net/ethernet.h> when checking for buggy ether_ntohost. Don't check for getipnodebyname(), since we don't use it. Use AC_SEARCH_LIBS instead of AC_CHECK_LIB for -lnsl, so that it doesn't get included when not needed. Redo AC_LBL_LIBRARY_NET to use AC_SEARCH_LIBS extensively.
2001-10-09 00:17:02 +08:00
dnl Use a cache variable name containing the library, function
dnl name, and extra libraries to link with, because the test really is
dnl for library $1 defining function $2, when linked with potinal
dnl library $5, not just for library $1. Separate tests with the same
dnl $1 and different $2's or $5's may have different results.
Initial revision
1999-10-08 07:47:09 +08:00
ac_lib_var=`echo $1['_']$2['_']$5 | sed 'y%./+- %__p__%'`
AC_CACHE_VAL(ac_cv_lbl_lib_$ac_lib_var,
[ac_save_LIBS="$LIBS"
LIBS="-l$1 $5 $LIBS"
AC_TRY_LINK(dnl
ifelse([$2], [main], , dnl Avoid conflicting decl of main.
[/* Override any gcc2 internal prototype to avoid an error. */
]ifelse(AC_LANG, CPLUSPLUS, [#ifdef __cplusplus
extern "C"
#endif
])dnl
[/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char $2();
]),
[$2()],
eval "ac_cv_lbl_lib_$ac_lib_var=yes",
eval "ac_cv_lbl_lib_$ac_lib_var=no")
LIBS="$ac_save_LIBS"
])dnl
if eval "test \"`echo '$ac_cv_lbl_lib_'$ac_lib_var`\" = yes"; then
AC_MSG_RESULT(yes)
ifelse([$3], ,
[changequote(, )dnl
ac_tr_lib=HAVE_LIB`echo $1 | sed -e 's/[^a-zA-Z0-9_]/_/g' \
-e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'`
changequote([, ])dnl
AC_DEFINE_UNQUOTED($ac_tr_lib)
LIBS="-l$1 $LIBS"
], [$3])
else
AC_MSG_RESULT(no)
ifelse([$4], , , [$4
])dnl
fi
])
dnl
dnl AC_LBL_LIBRARY_NET
dnl
dnl This test is for network applications that need socket() and
dnl gethostbyname() -ish functions. Under Solaris, those applications
dnl need to link with "-lsocket -lnsl". Under IRIX, they need to link
dnl with "-lnsl" but should *not* link with "-lsocket" because
dnl libsocket.a breaks a number of things (for instance:
dnl gethostbyname() under IRIX 5.2, and snoop sockets under most
dnl versions of IRIX).
dnl
dnl Unfortunately, many application developers are not aware of this,
dnl and mistakenly write tests that cause -lsocket to be used under
dnl IRIX. It is also easy to write tests that cause -lnsl to be used
dnl under operating systems where neither are necessary (or useful),
dnl such as SunOS 4.1.4, which uses -lnsl for TLI.
dnl
dnl This test exists so that every application developer does not test
dnl this in a different, and subtly broken fashion.
dnl It has been argued that this test should be broken up into two
Fix some spelling in comments. [skip ci]
2018-08-01 21:06:33 +08:00
dnl separate tests, one for the resolver libraries, and one for the
Initial revision
1999-10-08 07:47:09 +08:00
dnl libraries necessary for using Sockets API. Unfortunately, the two
dnl are carefully intertwined and allowing the autoconf user to use
Fix some spelling in comments. [skip ci]
2018-08-01 21:06:33 +08:00
dnl them independently potentially results in unfortunate ordering
dnl dependencies -- as such, such component macros would have to
Initial revision
1999-10-08 07:47:09 +08:00
dnl carefully use indirection and be aware if the other components were
dnl executed. Since other autoconf macros do not go to this trouble,
dnl and almost no applications use sockets without the resolver, this
dnl complexity has not been implemented.
dnl
dnl The check for libresolv is in case you are attempting to link
dnl statically and happen to have a libresolv.a lying around (and no
dnl libnsl.a).
dnl
AC_DEFUN(AC_LBL_LIBRARY_NET, [
# Most operating systems have gethostbyname() in the default searched
# libraries (i.e. libc):
Don't include <net/ethernet.h> when checking for buggy ether_ntohost. Don't check for getipnodebyname(), since we don't use it. Use AC_SEARCH_LIBS instead of AC_CHECK_LIB for -lnsl, so that it doesn't get included when not needed. Redo AC_LBL_LIBRARY_NET to use AC_SEARCH_LIBS extensively.
2001-10-09 00:17:02 +08:00
# Some OSes (eg. Solaris) place it in libnsl
# Some strange OSes (SINIX) have it in libsocket:
AC_SEARCH_LIBS(gethostbyname, nsl socket resolv)
# Unfortunately libsocket sometimes depends on libnsl and
# AC_SEARCH_LIBS isn't up to the task of handling dependencies like this.
if test "$ac_cv_search_gethostbyname" = "no"
then
AC_CHECK_LIB(socket, gethostbyname,
LIBS="-lsocket -lnsl $LIBS", , -lnsl)
fi
AC_SEARCH_LIBS(socket, socket, ,
AC_CHECK_LIB(socket, socket, LIBS="-lsocket -lnsl $LIBS", , -lnsl))
Initial revision
1999-10-08 07:47:09 +08:00
# DLPI needs putmsg under HPUX so test for -lstr while we're at it
Don't include <net/ethernet.h> when checking for buggy ether_ntohost. Don't check for getipnodebyname(), since we don't use it. Use AC_SEARCH_LIBS instead of AC_CHECK_LIB for -lnsl, so that it doesn't get included when not needed. Redo AC_LBL_LIBRARY_NET to use AC_SEARCH_LIBS extensively.
2001-10-09 00:17:02 +08:00
AC_SEARCH_LIBS(putmsg, str)
Initial revision
1999-10-08 07:47:09 +08:00
])
Bring in KAME IPv6 tcpdump. replaces esp/ah/isakmp decoder. Hope I did not break anything. Portability on IPv4-only node needs checking, I'll do this very soon. (sorry for rather jumbo commit) XXx what is _FAVOR_BSD?
1999-10-30 13:11:06 +08:00
dnl Copyright (c) 1999 WIDE Project. All rights reserved.
dnl
dnl Redistribution and use in source and binary forms, with or without
dnl modification, are permitted provided that the following conditions
dnl are met:
dnl 1. Redistributions of source code must retain the above copyright
dnl notice, this list of conditions and the following disclaimer.
dnl 2. Redistributions in binary form must reproduce the above copyright
dnl notice, this list of conditions and the following disclaimer in the
dnl documentation and/or other materials provided with the distribution.
dnl 3. Neither the name of the project nor the names of its contributors
dnl may be used to endorse or promote products derived from this software
dnl without specific prior written permission.
delete trailing spaces/tabs
2014-05-12 16:20:58 +08:00
dnl
Bring in KAME IPv6 tcpdump. replaces esp/ah/isakmp decoder. Hope I did not break anything. Portability on IPv4-only node needs checking, I'll do this very soon. (sorry for rather jumbo commit) XXx what is _FAVOR_BSD?
1999-10-30 13:11:06 +08:00
dnl THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
dnl ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
dnl IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
dnl ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
dnl FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
dnl DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
dnl OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
dnl HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
dnl LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
dnl OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
dnl SUCH DAMAGE.
Have --with-crypto take an optional argument, specifying where libcrypto can be found. If --with-crypto is specified, and libcrypto isn't found, fail, as presumably the user expected libcrypto to be available.
2008-02-27 04:47:12 +08:00
AC_DEFUN(AC_LBL_SSLEAY,
[
From Michael Riepe: On e.g. an x86_64 Linux system, configure won't find libcrypto because it's located in .../lib64. As a temporal workaround, use the last part of $libdir instead of "lib". On the long run, AC_LBL_SSLEAY should probably be rewritten.
2009-03-24 23:42:47 +08:00
#
# Find the last component of $libdir; it's not necessarily
# "lib" - it might be "lib64" on, for example, x86-64
# Linux systems.
#
# We assume the directory in which we're looking for
# libcrypto has a subdirectory with that as its name.
#
tmplib=`echo "$libdir" | sed 's,.*/,,'`
Have --with-crypto take an optional argument, specifying where libcrypto can be found. If --with-crypto is specified, and libcrypto isn't found, fail, as presumably the user expected libcrypto to be available.
2008-02-27 04:47:12 +08:00
#
# XXX - is there a better way to check if a given library is
# in a given directory than checking each of the possible
# shared library suffixes?
#
# Are there any other suffixes we need to look for? Do we
# have to worry about ".so.{version}"?
#
# Or should we just look for "libcrypto.*"?
#
From Michael Riepe: On e.g. an x86_64 Linux system, configure won't find libcrypto because it's located in .../lib64. As a temporal workaround, use the last part of $libdir instead of "lib". On the long run, AC_LBL_SSLEAY should probably be rewritten.
2009-03-24 23:42:47 +08:00
if test -d "$1/$tmplib" -a \( -f "$1/$tmplib/libcrypto.a" -o \
Fix spaces
2018-09-03 20:03:25 +08:00
-f "$1/$tmplib/libcrypto.so" -o \
-f "$1/$tmplib/libcrypto.sl" -o \
-f "$1/$tmplib/libcrypto.dylib" \); then
Have --with-crypto take an optional argument, specifying where libcrypto can be found. If --with-crypto is specified, and libcrypto isn't found, fail, as presumably the user expected libcrypto to be available.
2008-02-27 04:47:12 +08:00
ac_cv_ssleay_path="$1"
fi
#
# Make sure we have the headers as well.
#
if test -d "$1/include/openssl" -a -f "$1/include/openssl/des.h"; then
incdir="-I$1/include"
fi
])
Reference in New Issue Copy Permalink