2009-07-08 13:19:16 -07:00
|
|
|
# -*- autoconf -*-
|
|
|
|
|
|
2011-01-12 13:08:08 -08:00
|
|
|
# Copyright (c) 2008, 2009, 2010, 2011 Nicira Networks.
|
2009-07-08 13:19:16 -07:00
|
|
|
#
|
2009-06-15 15:11:30 -07:00
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
|
# You may obtain a copy of the License at:
|
2009-07-08 13:19:16 -07:00
|
|
|
#
|
2009-06-15 15:11:30 -07:00
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
#
|
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
|
# limitations under the License.
|
2009-07-08 13:19:16 -07:00
|
|
|
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
dnl OVS_CHECK_LINUX26
|
2009-07-08 13:19:16 -07:00
|
|
|
dnl
|
|
|
|
|
dnl Configure linux kernel source tree
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
AC_DEFUN([OVS_CHECK_LINUX26], [
|
|
|
|
|
AC_ARG_WITH([l26],
|
|
|
|
|
[AC_HELP_STRING([--with-l26=/path/to/linux-2.6],
|
2010-07-02 10:10:04 -07:00
|
|
|
[Specify the linux 2.6 kernel build directory])],
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
[KBUILD26="$withval"], [KBUILD26=])dnl
|
2010-07-02 10:10:04 -07:00
|
|
|
AC_ARG_WITH([l26-source],
|
|
|
|
|
[AC_HELP_STRING([--with-l26-source=/path/to/linux-2.6-source],
|
|
|
|
|
[Specify the linux 2.6 kernel source directory
|
|
|
|
|
(usually figured out automatically from build
|
|
|
|
|
directory)])],
|
|
|
|
|
[KSRC26="$withval"], [KSRC26=])dnl
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
if test -n "$KBUILD26"; then
|
|
|
|
|
KBUILD26=`eval echo "$KBUILD26"`
|
2010-04-13 15:08:37 -07:00
|
|
|
case $KBUILD26 in
|
|
|
|
|
/*) ;;
|
|
|
|
|
*) KBUILD26=`pwd`/$KBUILD26 ;;
|
|
|
|
|
esac
|
2009-07-08 13:19:16 -07:00
|
|
|
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
# The build directory is what the user provided.
|
|
|
|
|
# Make sure that it exists.
|
|
|
|
|
AC_MSG_CHECKING([for Linux 2.6 build directory])
|
|
|
|
|
if test -d "$KBUILD26"; then
|
|
|
|
|
AC_MSG_RESULT([$KBUILD26])
|
|
|
|
|
AC_SUBST(KBUILD26)
|
2009-07-08 13:19:16 -07:00
|
|
|
else
|
|
|
|
|
AC_MSG_RESULT([no])
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
AC_ERROR([source dir $KBUILD26 doesn't exist])
|
2009-07-08 13:19:16 -07:00
|
|
|
fi
|
|
|
|
|
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
# Debian breaks kernel headers into "source" header and "build" headers.
|
|
|
|
|
# We want the source headers, but $KBUILD26 gives us the "build" headers.
|
|
|
|
|
# Use heuristics to find the source headers.
|
|
|
|
|
AC_MSG_CHECKING([for Linux 2.6 source directory])
|
2010-07-02 10:10:04 -07:00
|
|
|
if test -n "$KSRC26"; then
|
|
|
|
|
KSRC26=`eval echo "$KSRC26"`
|
|
|
|
|
case $KSRC26 in
|
|
|
|
|
/*) ;;
|
|
|
|
|
*) KSRC26=`pwd`/$KSRC26 ;;
|
2010-01-08 13:09:10 -08:00
|
|
|
esac
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
if test ! -e $KSRC26/include/linux/kernel.h; then
|
2010-07-02 10:10:04 -07:00
|
|
|
AC_MSG_ERROR([$KSRC26 is not a kernel source directory)])
|
|
|
|
|
fi
|
|
|
|
|
else
|
|
|
|
|
KSRC26=$KBUILD26
|
|
|
|
|
if test ! -e $KSRC26/include/linux/kernel.h; then
|
|
|
|
|
case `echo "$KBUILD26" | sed 's,/*$,,'` in # (
|
|
|
|
|
*/build)
|
|
|
|
|
KSRC26=`echo "$KBUILD26" | sed 's,/build/*$,/source,'`
|
|
|
|
|
;; # (
|
|
|
|
|
*)
|
|
|
|
|
KSRC26=`(cd $KBUILD26 && pwd -P) | sed 's,-[[^-]]*$,-common,'`
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
fi
|
|
|
|
|
if test ! -e $KSRC26/include/linux/kernel.h; then
|
|
|
|
|
AC_MSG_ERROR([cannot find source directory (please use --with-l26-source)])
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
fi
|
|
|
|
|
fi
|
|
|
|
|
AC_MSG_RESULT([$KSRC26])
|
|
|
|
|
|
|
|
|
|
AC_MSG_CHECKING([for kernel version])
|
|
|
|
|
patchlevel=`sed -n 's/^PATCHLEVEL = //p' "$KSRC26/Makefile"`
|
|
|
|
|
sublevel=`sed -n 's/^SUBLEVEL = //p' "$KSRC26/Makefile"`
|
|
|
|
|
if test -z "$patchlevel" || test -z "$sublevel"; then
|
|
|
|
|
AC_ERROR([cannot determine kernel version])
|
|
|
|
|
fi
|
2009-07-08 13:19:16 -07:00
|
|
|
AC_MSG_RESULT([2.$patchlevel.$sublevel])
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
if test "2.$patchlevel" != '2.6'; then
|
|
|
|
|
if test "$BUILD26" = "$KSRC26"; then
|
|
|
|
|
AC_ERROR([Linux kernel in $KBUILD26 is not version 2.6])
|
|
|
|
|
else
|
|
|
|
|
AC_ERROR([Linux kernel in build tree $KBUILD26 (source tree $KSRC26) is not version 2.6])
|
|
|
|
|
fi
|
2009-07-08 13:19:16 -07:00
|
|
|
fi
|
2010-03-23 09:27:08 -07:00
|
|
|
if test ! -e "$KBUILD26"/include/linux/version.h || \
|
|
|
|
|
(test ! -e "$KBUILD26"/include/linux/autoconf.h && \
|
|
|
|
|
test ! -e "$KBUILD26"/include/generated/autoconf.h); then
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
AC_MSG_ERROR([Linux kernel source in $KBUILD26 is not configured])
|
2009-07-08 13:19:16 -07:00
|
|
|
fi
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
OVS_CHECK_LINUX26_COMPAT
|
2010-07-02 10:10:04 -07:00
|
|
|
elif test -n "$KSRC26"; then
|
|
|
|
|
AC_MSG_ERROR([--with-l26-source may not be specified without --with-l26])
|
2009-07-08 13:19:16 -07:00
|
|
|
fi
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
AM_CONDITIONAL(L26_ENABLED, test -n "$KBUILD26")
|
2009-07-08 13:19:16 -07:00
|
|
|
])
|
|
|
|
|
|
2010-09-08 16:46:43 -07:00
|
|
|
dnl OVS_GREP_IFELSE(FILE, REGEX, [IF-MATCH], [IF-NO-MATCH])
|
2009-07-08 13:19:16 -07:00
|
|
|
dnl
|
|
|
|
|
dnl Greps FILE for REGEX. If it matches, runs IF-MATCH, otherwise IF-NO-MATCH.
|
2010-09-08 16:46:43 -07:00
|
|
|
dnl If IF-MATCH is empty then it defines to OVS_DEFINE(HAVE_<REGEX>), with
|
|
|
|
|
dnl <REGEX> translated to uppercase.
|
2009-07-08 13:19:16 -07:00
|
|
|
AC_DEFUN([OVS_GREP_IFELSE], [
|
|
|
|
|
AC_MSG_CHECKING([whether $2 matches in $1])
|
2010-11-02 16:00:16 -07:00
|
|
|
if test -f $1; then
|
|
|
|
|
grep '$2' $1 >/dev/null 2>&1
|
|
|
|
|
status=$?
|
|
|
|
|
case $status in
|
|
|
|
|
0)
|
|
|
|
|
AC_MSG_RESULT([yes])
|
2010-09-08 16:46:43 -07:00
|
|
|
m4_if([$3], [], [OVS_DEFINE([HAVE_]m4_toupper([$2]))], [$3])
|
2010-11-02 16:00:16 -07:00
|
|
|
;;
|
|
|
|
|
1)
|
|
|
|
|
AC_MSG_RESULT([no])
|
|
|
|
|
$4
|
|
|
|
|
;;
|
|
|
|
|
*)
|
|
|
|
|
AC_MSG_ERROR([grep exited with status $status])
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
else
|
|
|
|
|
AC_MSG_RESULT([file not found])
|
|
|
|
|
$4
|
|
|
|
|
fi
|
2009-07-08 13:19:16 -07:00
|
|
|
])
|
|
|
|
|
|
|
|
|
|
dnl OVS_DEFINE(NAME)
|
|
|
|
|
dnl
|
|
|
|
|
dnl Defines NAME to 1 in kcompat.h.
|
|
|
|
|
AC_DEFUN([OVS_DEFINE], [
|
|
|
|
|
echo '#define $1 1' >> datapath/linux-2.6/kcompat.h.new
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
AC_DEFUN([OVS_CHECK_LOG2_H], [
|
|
|
|
|
AC_MSG_CHECKING([for $KSRC26/include/linux/log2.h])
|
|
|
|
|
if test -e $KSRC26/include/linux/log2.h; then
|
|
|
|
|
AC_MSG_RESULT([yes])
|
|
|
|
|
OVS_DEFINE([HAVE_LOG2_H])
|
|
|
|
|
else
|
|
|
|
|
AC_MSG_RESULT([no])
|
|
|
|
|
fi
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
dnl OVS_CHECK_LINUX26_COMPAT
|
|
|
|
|
dnl
|
|
|
|
|
dnl Runs various Autoconf checks on the Linux 2.6 kernel source in
|
datapath: Fix build with kernel header layout recently adopted by Debian.
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
2009-11-18 11:05:00 -08:00
|
|
|
dnl the directory in $KBUILD26.
|
2009-07-08 13:19:16 -07:00
|
|
|
AC_DEFUN([OVS_CHECK_LINUX26_COMPAT], [
|
|
|
|
|
rm -f datapath/linux-2.6/kcompat.h.new
|
|
|
|
|
mkdir -p datapath/linux-2.6
|
|
|
|
|
: > datapath/linux-2.6/kcompat.h.new
|
2010-05-14 15:39:48 -07:00
|
|
|
|
2010-11-02 15:43:32 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/arch/x86/include/asm/checksum_32.h], [src_err,],
|
|
|
|
|
[OVS_DEFINE([HAVE_CSUM_COPY_DBG])])
|
|
|
|
|
|
2010-09-08 16:46:43 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/err.h], [ERR_CAST])
|
2010-05-14 15:39:48 -07:00
|
|
|
|
2010-09-08 16:46:43 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/in.h], [ipv4_is_multicast])
|
2010-05-14 15:39:48 -07:00
|
|
|
|
2010-09-08 16:46:43 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/netdevice.h], [dev_disable_lro])
|
|
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/netdevice.h], [dev_get_stats])
|
2010-05-14 15:39:48 -07:00
|
|
|
|
2011-02-07 17:22:58 -08:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/rcupdate.h], [rcu_read_lock_held], [],
|
|
|
|
|
[OVS_GREP_IFELSE([$KSRC26/include/linux/rtnetlink.h],
|
|
|
|
|
[rcu_read_lock_held])])
|
|
|
|
|
|
2009-11-18 15:19:50 -08:00
|
|
|
# Check for the proto_data_valid member in struct sk_buff. The [^@]
|
|
|
|
|
# is necessary because some versions of this header remove the
|
|
|
|
|
# member but retain the kerneldoc comment that describes it (which
|
|
|
|
|
# starts with @). The brackets must be doubled because of m4
|
|
|
|
|
# quoting rules.
|
|
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/skbuff.h], [[[^@]]proto_data_valid],
|
|
|
|
|
[OVS_DEFINE([HAVE_PROTO_DATA_VALID])])
|
2010-05-14 15:39:48 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/skbuff.h], [raw],
|
|
|
|
|
[OVS_DEFINE([HAVE_MAC_RAW])])
|
2010-05-14 15:44:39 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/skbuff.h], [skb_dst(],
|
|
|
|
|
[OVS_DEFINE([HAVE_SKB_DST_ACCESSOR_FUNCS])])
|
2010-05-14 15:39:48 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/skbuff.h],
|
2010-09-08 16:46:43 -07:00
|
|
|
[skb_copy_from_linear_data_offset])
|
|
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/skbuff.h], [skb_cow_head])
|
2010-05-14 15:39:48 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/skbuff.h], [skb_transport_header],
|
|
|
|
|
[OVS_DEFINE([HAVE_SKBUFF_HEADER_HELPERS])])
|
2010-12-29 19:03:46 -08:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/icmpv6.h], [icmp6_hdr],
|
|
|
|
|
[OVS_DEFINE([HAVE_ICMP6_HDR])])
|
2010-05-14 15:39:48 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/skbuff.h], [skb_warn_if_lro],
|
|
|
|
|
[OVS_DEFINE([HAVE_SKB_WARN_LRO])])
|
|
|
|
|
|
2010-09-08 16:46:43 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/string.h], [kmemdup], [],
|
|
|
|
|
[OVS_GREP_IFELSE([$KSRC26/include/linux/slab.h], [kmemdup])])
|
2010-05-14 15:39:48 -07:00
|
|
|
|
|
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/types.h], [bool],
|
|
|
|
|
[OVS_DEFINE([HAVE_BOOL_TYPE])])
|
2010-09-08 10:04:47 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/types.h], [__wsum],
|
|
|
|
|
[OVS_DEFINE([HAVE_CSUM_TYPES])])
|
2010-05-14 15:39:48 -07:00
|
|
|
|
2011-01-19 09:29:06 -08:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/net/checksum.h], [csum_replace4])
|
2010-09-08 16:46:43 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/net/checksum.h], [csum_unfold])
|
2010-05-14 15:39:48 -07:00
|
|
|
|
2010-09-08 16:46:43 -07:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/net/netlink.h], [NLA_NUL_STRING])
|
|
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/net/netlink.h], [nla_get_be16])
|
2011-01-12 13:08:08 -08:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/net/netlink.h], [nla_find_nested])
|
2010-05-14 15:39:48 -07:00
|
|
|
|
datapath: Tolerate backporting of rtnl_link_stats64 (as in RHEL 6).
Red Hat Enterprise Linux 6 has a 2.6.32 kernel but it backports the
rtnl_link_stats64 structure that was introduced in 2.6.35, so we need to
check whether it was defined instead of just guessing based on the kernel
version number.
Build-tested only, on 2.6.32-71.14.1.el6 (RHEL 6),
linux-2.6.18-128.1.6.el5.xs5.5.0.496.101 (XenServer 5.5.0),
2.6.18-128.1.6.el5.xs5.5.0.505.1024xen (XenServer 5.5.0 update 1),
and upstream 2.6.18, 2.6.26, 2.6.29, 2.6.33, 2.6.34, 2.6.36, all for i386,
plus 2.6.36 for x86-64.
My machine's userspace headers have <linux/if_link.h> but not
rtnl_link_stats64. Jesse Gross tested the case where <linux/if_link.h>
has rtnl_link_stats64, on Ubuntu 10.10.
Reported-by: Geoff White <gwhite@nicira.com>
Tested-by: Jesse Gross <jesse@nicira.com>
2011-02-04 12:35:49 -08:00
|
|
|
OVS_GREP_IFELSE([$KSRC26/include/linux/if_link.h], [rtnl_link_stats64])
|
|
|
|
|
|
2009-07-08 13:19:16 -07:00
|
|
|
OVS_CHECK_LOG2_H
|
2010-05-14 15:39:48 -07:00
|
|
|
|
2009-07-08 13:19:16 -07:00
|
|
|
if cmp -s datapath/linux-2.6/kcompat.h.new \
|
|
|
|
|
datapath/linux-2.6/kcompat.h >/dev/null 2>&1; then
|
|
|
|
|
rm datapath/linux-2.6/kcompat.h.new
|
|
|
|
|
else
|
|
|
|
|
mv datapath/linux-2.6/kcompat.h.new datapath/linux-2.6/kcompat.h
|
|
|
|
|
fi
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
dnl Checks for net/if_packet.h.
|
|
|
|
|
AC_DEFUN([OVS_CHECK_IF_PACKET],
|
|
|
|
|
[AC_CHECK_HEADER([net/if_packet.h],
|
|
|
|
|
[HAVE_IF_PACKET=yes],
|
|
|
|
|
[HAVE_IF_PACKET=no])
|
|
|
|
|
AM_CONDITIONAL([HAVE_IF_PACKET], [test "$HAVE_IF_PACKET" = yes])
|
|
|
|
|
if test "$HAVE_IF_PACKET" = yes; then
|
|
|
|
|
AC_DEFINE([HAVE_IF_PACKET], [1],
|
|
|
|
|
[Define to 1 if net/if_packet.h is available.])
|
|
|
|
|
fi])
|
|
|
|
|
|
2009-06-10 14:16:40 -07:00
|
|
|
dnl Checks for buggy strtok_r.
|
|
|
|
|
dnl
|
|
|
|
|
dnl Some versions of glibc 2.7 has a bug in strtok_r when compiling
|
|
|
|
|
dnl with optimization that can cause segfaults:
|
|
|
|
|
dnl
|
|
|
|
|
dnl http://sources.redhat.com/bugzilla/show_bug.cgi?id=5614.
|
|
|
|
|
AC_DEFUN([OVS_CHECK_STRTOK_R],
|
|
|
|
|
[AC_CACHE_CHECK(
|
|
|
|
|
[whether strtok_r macro segfaults on some inputs],
|
|
|
|
|
[ovs_cv_strtok_r_bug],
|
|
|
|
|
[AC_RUN_IFELSE(
|
|
|
|
|
[AC_LANG_PROGRAM([#include <stdio.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
],
|
|
|
|
|
[[char string[] = ":::";
|
|
|
|
|
char *save_ptr = (char *) 0xc0ffee;
|
|
|
|
|
char *token1, *token2;
|
|
|
|
|
token1 = strtok_r(string, ":", &save_ptr);
|
|
|
|
|
token2 = strtok_r(NULL, ":", &save_ptr);
|
2010-01-25 10:32:39 -08:00
|
|
|
freopen ("/dev/null", "w", stdout);
|
2009-06-10 14:16:40 -07:00
|
|
|
printf ("%s %s\n", token1, token2);
|
|
|
|
|
return 0;
|
|
|
|
|
]])],
|
|
|
|
|
[ovs_cv_strtok_r_bug=no],
|
|
|
|
|
[ovs_cv_strtok_r_bug=yes],
|
|
|
|
|
[ovs_cv_strtok_r_bug=yes])])
|
|
|
|
|
if test $ovs_cv_strtok_r_bug = yes; then
|
|
|
|
|
AC_DEFINE([HAVE_STRTOK_R_BUG], [1],
|
|
|
|
|
[Define if strtok_r macro segfaults on some inputs])
|
|
|
|
|
fi
|
|
|
|
|
])
|
|
|
|
|
|
2009-07-08 13:19:16 -07:00
|
|
|
dnl ----------------------------------------------------------------------
|
|
|
|
|
dnl These macros are from GNU PSPP, with the following original license:
|
|
|
|
|
dnl Copyright (C) 2005, 2006, 2007 Free Software Foundation, Inc.
|
|
|
|
|
dnl This file is free software; the Free Software Foundation
|
|
|
|
|
dnl gives unlimited permission to copy and/or distribute it,
|
|
|
|
|
dnl with or without modifications, as long as this notice is preserved.
|
|
|
|
|
|
|
|
|
|
dnl OVS_CHECK_CC_OPTION([OPTION], [ACTION-IF-ACCEPTED], [ACTION-IF-REJECTED])
|
|
|
|
|
dnl Check whether the given C compiler OPTION is accepted.
|
|
|
|
|
dnl If so, execute ACTION-IF-ACCEPTED, otherwise ACTION-IF-REJECTED.
|
|
|
|
|
AC_DEFUN([OVS_CHECK_CC_OPTION],
|
|
|
|
|
[
|
|
|
|
|
m4_define([ovs_cv_name], [ovs_cv_[]m4_translit([$1], [-], [_])])dnl
|
|
|
|
|
AC_CACHE_CHECK([whether $CC accepts $1], [ovs_cv_name],
|
|
|
|
|
[ovs_save_CFLAGS="$CFLAGS"
|
|
|
|
|
CFLAGS="$CFLAGS $1"
|
|
|
|
|
AC_COMPILE_IFELSE([AC_LANG_PROGRAM(,)], [ovs_cv_name[]=yes], [ovs_cv_name[]=no])
|
|
|
|
|
CFLAGS="$ovs_save_CFLAGS"])
|
|
|
|
|
if test $ovs_cv_name = yes; then
|
2009-11-18 16:27:55 -08:00
|
|
|
m4_if([$2], [], [:], [$2])
|
2009-07-08 13:19:16 -07:00
|
|
|
else
|
|
|
|
|
m4_if([$3], [], [:], [$3])
|
|
|
|
|
fi
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
dnl OVS_ENABLE_OPTION([OPTION])
|
|
|
|
|
dnl Check whether the given C compiler OPTION is accepted.
|
2009-11-19 13:25:42 -08:00
|
|
|
dnl If so, add it to WARNING_FLAGS.
|
2009-07-08 13:19:16 -07:00
|
|
|
dnl Example: OVS_ENABLE_OPTION([-Wdeclaration-after-statement])
|
|
|
|
|
AC_DEFUN([OVS_ENABLE_OPTION],
|
2009-11-19 13:25:42 -08:00
|
|
|
[OVS_CHECK_CC_OPTION([$1], [WARNING_FLAGS="$WARNING_FLAGS $1"])
|
|
|
|
|
AC_SUBST([WARNING_FLAGS])])
|
2009-11-20 09:45:26 -08:00
|
|
|
|
|
|
|
|
dnl OVS_CONDITIONAL_CC_OPTION([OPTION], [CONDITIONAL])
|
|
|
|
|
dnl Check whether the given C compiler OPTION is accepted.
|
|
|
|
|
dnl If so, enable the given Automake CONDITIONAL.
|
|
|
|
|
|
|
|
|
|
dnl Example: OVS_CONDITIONAL_CC_OPTION([-Wno-unused], [HAVE_WNO_UNUSED])
|
|
|
|
|
AC_DEFUN([OVS_CONDITIONAL_CC_OPTION],
|
|
|
|
|
[OVS_CHECK_CC_OPTION(
|
|
|
|
|
[$1], [ovs_have_cc_option=yes], [ovs_have_cc_option=no])
|
|
|
|
|
AM_CONDITIONAL([$2], [test $ovs_have_cc_option = yes])])
|
2009-07-08 13:19:16 -07:00
|
|
|
dnl ----------------------------------------------------------------------
|
