Fix --with-kernel for libnfnetlink

Fix --with-kernel for libnfnetlink

[David Vogt]

Hi,

Amin Azez has helped me with some trouble concerning the compilation
of libnfnetlink.
The --with-kernel parameter for the configure script did not work as
intended, so Amin has proposed the following changes that 1) look for
the kernel sources 2) recognise --with-kernel parameter.

Index: configure.in
===================================================================
--- configure.in	(revision 6582)
+++ configure.in	(working copy)
@@ -18,6 +18,47 @@


 dnl--------------------------------
+AC_DEFUN([NF_KERNEL_SOURCE],[
+
+ if test "$with_kernel" = ""; then
+   KERNEL="`uname -r`"
+ else
+   KERNEL="$with_kernel"
+ fi
+
+ THIS_PREFIX=""
+ for i in "/lib/modules/$KERNEL/build/include" "$KERNEL"
"$KERNEL/include" "/usr/src/linux-$KERNEL" "/usr/src/kernel-$KERNEL"
"/usr/src/linux-headers-$KERNEL" "/usr/src/kernel-headers-$KERNEL"
+ do
+   AC_MSG_CHECKING([Looking for kernel source or headers in $i])
+   if test -r "$i/linux/config.h"
+   then
+     THIS_PREFIX="$i"
+     AC_MSG_RESULT([found])
+     break
+   fi
+   AC_MSG_RESULT([ ])
+ done
+ if test -r "$THIS_PREFIX/linux/config.h" ; then
+   AC_SUBST(KERNELDIR,[$THIS_PREFIX])
+   AC_MSG_RESULT([found])
+ else
+   AC_MSG_ERROR([not found $THIS_PREFIX])
+ fi
+
+ # somehow add this as an include path
+])
+
+AC_ARG_WITH(kernel,
+              AC_HELP_STRING([--with-kernel=DIR],
+                             [ Show location of kernel source.
Default is to use uname -r and look in
/lib/modules/KERNEL/build/include. ]),
+              NF_KERNEL_SOURCE($with_kernel),NF_KERNEL_SOURCE())
+
+if test ! -z "$libdir"; then
+  MODULE_DIR="\\\"$libdir/\\\""
+  CFLAGS="$CFLAGS -DCONNTRACK_LIB_DIR=$MODULE_DIR"
+fi
+
+
 dnl--------------------------------


Index: src/Makefile.am
===================================================================
--- src/Makefile.am	(revision 6582)
+++ src/Makefile.am	(working copy)
@@ -2,7 +2,7 @@
 # Please read Chapter 6 "Library interface versions" of the libtool
documentation before making any modification
 LIBVERSION=1:0:0

-INCLUDES = $(all_includes) -I$(top_srcdir)/include
+INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(KERNELDIR)
 AM_CFLAGS=-fPIC -Wall
 LIBS=

Re: Fix --with-kernel for libnfnetlink

[Amin Azez]

A similar change is probably good for libctnetlink and any other 
projects that look for kernel headers,

Sam

David Vogt wrote:
> Hi,
> 
> Amin Azez has helped me with some trouble concerning the compilation
> of libnfnetlink.
> The --with-kernel parameter for the configure script did not work as
> intended, so Amin has proposed the following changes that 1) look for
> the kernel sources 2) recognise --with-kernel parameter.
> 
> Index: configure.in
> ===================================================================
> --- configure.in	(revision 6582)
> +++ configure.in	(working copy)
> @@ -18,6 +18,47 @@
> 
> 
>  dnl--------------------------------
> +AC_DEFUN([NF_KERNEL_SOURCE],[
> +
> + if test "$with_kernel" = ""; then
> +   KERNEL="`uname -r`"
> + else
> +   KERNEL="$with_kernel"
> + fi
> +
> + THIS_PREFIX=""
> + for i in "/lib/modules/$KERNEL/build/include" "$KERNEL"
> "$KERNEL/include" "/usr/src/linux-$KERNEL" "/usr/src/kernel-$KERNEL"
> "/usr/src/linux-headers-$KERNEL" "/usr/src/kernel-headers-$KERNEL"
> + do
> +   AC_MSG_CHECKING([Looking for kernel source or headers in $i])
> +   if test -r "$i/linux/config.h"
> +   then
> +     THIS_PREFIX="$i"
> +     AC_MSG_RESULT([found])
> +     break
> +   fi
> +   AC_MSG_RESULT([ ])
> + done
> + if test -r "$THIS_PREFIX/linux/config.h" ; then
> +   AC_SUBST(KERNELDIR,[$THIS_PREFIX])
> +   AC_MSG_RESULT([found])
> + else
> +   AC_MSG_ERROR([not found $THIS_PREFIX])
> + fi
> +
> + # somehow add this as an include path
> +])
> +
> +AC_ARG_WITH(kernel,
> +              AC_HELP_STRING([--with-kernel=DIR],
> +                             [ Show location of kernel source.
> Default is to use uname -r and look in
> /lib/modules/KERNEL/build/include. ]),
> +              NF_KERNEL_SOURCE($with_kernel),NF_KERNEL_SOURCE())
> +
> +if test ! -z "$libdir"; then
> +  MODULE_DIR="\\\"$libdir/\\\""
> +  CFLAGS="$CFLAGS -DCONNTRACK_LIB_DIR=$MODULE_DIR"
> +fi
> +
> +
>  dnl--------------------------------
> 
> 
> Index: src/Makefile.am
> ===================================================================
> --- src/Makefile.am	(revision 6582)
> +++ src/Makefile.am	(working copy)
> @@ -2,7 +2,7 @@
>  # Please read Chapter 6 "Library interface versions" of the libtool
> documentation before making any modification
>  LIBVERSION=1:0:0
> 
> -INCLUDES = $(all_includes) -I$(top_srcdir)/include
> +INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(KERNELDIR)
>  AM_CFLAGS=-fPIC -Wall
>  LIBS=
> 
> 

Re: Fix --with-kernel for libnfnetlink

[Sven-Haegar Koch]

On Thu, 20 Apr 2006, David Vogt wrote:

> Amin Azez has helped me with some trouble concerning the compilation
> of libnfnetlink.
> The --with-kernel parameter for the configure script did not work as
> intended, so Amin has proposed the following changes that 1) look for
> the kernel sources 2) recognise --with-kernel parameter.

[...]

> + if test "$with_kernel" = ""; then
> +   KERNEL="`uname -r`"
> + else
> +   KERNEL="$with_kernel"
> + fi

Shouldn't --with-kernel let me specify a kernel source directory, instead 
of a kernel version and then using some heuristicts to find the source 
directory? (The heuristic for the default using /lib/modules/`uname 
-r`/build is fine)

(My used kernel sources for example live under ~/kernel/....)

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

Re: Fix --with-kernel for libnfnetlink

[Patrick McHardy]

Sven-Haegar Koch wrote:
>> + if test "$with_kernel" = ""; then
>> +   KERNEL="`uname -r`"
>> + else
>> +   KERNEL="$with_kernel"
>> + fi
> 
> 
> Shouldn't --with-kernel let me specify a kernel source directory,
> instead of a kernel version and then using some heuristicts to find the
> source directory? (The heuristic for the default using
> /lib/modules/`uname -r`/build is fine)

I agree, if someone sends me a patch to change it I'll apply it.

Re: Fix --with-kernel for libnfnetlink

[Patrick McHardy]

Patrick McHardy wrote:
> Sven-Haegar Koch wrote:
> 
>>Shouldn't --with-kernel let me specify a kernel source directory,
>>instead of a kernel version and then using some heuristicts to find the
>>source directory? (The heuristic for the default using
>>/lib/modules/`uname -r`/build is fine)
> 
> 
> I agree, if someone sends me a patch to change it I'll apply it.
> 

D'oh, just saw the patch :)

Re: Fix --with-kernel for libnfnetlink

[KOVACS Krisztian]

  Hi,

On Thu, Apr 20, 2006 at 08:51:37PM +0200, Patrick McHardy wrote:
> > Shouldn't --with-kernel let me specify a kernel source directory,
> > instead of a kernel version and then using some heuristicts to find the
> > source directory? (The heuristic for the default using
> > /lib/modules/`uname -r`/build is fine)
> 
> I agree, if someone sends me a patch to change it I'll apply it.

  Is there any chance of getting the pkg-config related modifications
merged as well?

  http://tinyurl.com/mnw9c

-- 
 KOVACS Krisztian

Re: Fix --with-kernel for libnfnetlink

[Patrick McHardy]

KOVACS Krisztian wrote:
>   Is there any chance of getting the pkg-config related modifications
> merged as well?
> 
>   http://tinyurl.com/mnw9c

I saw the patch, but didn't apply it because its mostly Harald and
Pablo who work on that code.

@Harald, Pablo: any objections against applying this?

Re: Fix --with-kernel for libnfnetlink

[Pablo Neira Ayuso]

On Fri, Apr 21, 2006 at 12:52:10AM +0200, Patrick McHardy wrote:
> KOVACS Krisztian wrote:
> >   Is there any chance of getting the pkg-config related modifications
> > merged as well?
> > 
> >   http://tinyurl.com/mnw9c
> 
> I saw the patch, but didn't apply it because its mostly Harald and
> Pablo who work on that code.
> 
> @Harald, Pablo: any objections against applying this?

No objections from my part, pkg-config is present in most distros AFAIK,
and we needed a way to explicitely set the version dependencies between
libraries.

Re: Fix --with-kernel for libnfnetlink

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

On Fri, Apr 21, 2006 at 05:25:20PM +0200, Pablo Neira Ayuso wrote:
> On Fri, Apr 21, 2006 at 12:52:10AM +0200, Patrick McHardy wrote:
> > KOVACS Krisztian wrote:
> > >   Is there any chance of getting the pkg-config related modifications
> > > merged as well?
> > > 
> > >   http://tinyurl.com/mnw9c
> > 
> > I saw the patch, but didn't apply it because its mostly Harald and
> > Pablo who work on that code.
> > 
> > @Harald, Pablo: any objections against applying this?
> 
> No objections from my part, pkg-config is present in most distros AFAIK,
> and we needed a way to explicitely set the version dependencies between
>  libraries.

I agree. please apply.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Fix --with-kernel for libnfnetlink

[Patrick McHardy]

David Vogt wrote:
> Amin Azez has helped me with some trouble concerning the compilation
> of libnfnetlink.
> The --with-kernel parameter for the configure script did not work as
> intended, so Amin has proposed the following changes that 1) look for
> the kernel sources 2) recognise --with-kernel parameter.

Please change this to use --kernel as literal path as suggested
by Sven Koch.

Re: Fix --with-kernel for libnfnetlink

[David Vogt]

2006/4/20, Patrick McHardy <kaber@trash.net>:
> David Vogt wrote:
> > Amin Azez has helped me with some trouble concerning the compilation
> > of libnfnetlink.
> > The --with-kernel parameter for the configure script did not work as
> > intended, so Amin has proposed the following changes that 1) look for
> > the kernel sources 2) recognise --with-kernel parameter.
>
> Please change this to use --kernel as literal path as suggested
> by Sven Koch.

Like this?

Index: configure.in
===================================================================
--- configure.in	(revision 6583)
+++ configure.in	(working copy)
@@ -18,6 +18,35 @@


 dnl--------------------------------
+AC_DEFUN([NF_KERNEL_SOURCE],[
+
+ if test "$with_kernel" = ""; then
+   KERNEL="/lib/modules/`uname -r`/build"
+ else
+   KERNEL="$with_kernel"
+ fi
+
+ AC_MSG_CHECKING([for kernel headers in $KERNEL/include])
+ if test -r "$KERNEL/include/linux/config.h" ; then
+   AC_SUBST(KERNELDIR,[$KERNEL])
+   AC_MSG_RESULT([found])
+ else
+   AC_MSG_ERROR([not found])
+ fi
+
+])
+
+AC_ARG_WITH(kernel,
+              AC_HELP_STRING([--with-kernel=DIR],
+                             [ Show location of kernel source.
Default is to use uname -r and look in
/lib/modules/KERNEL/build/include. ]),
+              NF_KERNEL_SOURCE($with_kernel),NF_KERNEL_SOURCE())
+
+if test ! -z "$libdir"; then
+  MODULE_DIR="\\\"$libdir/\\\""
+  CFLAGS="$CFLAGS -DCONNTRACK_LIB_DIR=$MODULE_DIR"
+fi
+
+
 dnl--------------------------------


Index: src/Makefile.am
===================================================================
--- src/Makefile.am	(revision 6583)
+++ src/Makefile.am	(working copy)
@@ -2,7 +2,7 @@
 # Please read Chapter 6 "Library interface versions" of the libtool
documentation before making any modification
 LIBVERSION=1:0:0

-INCLUDES = $(all_includes) -I$(top_srcdir)/include
+INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(KERNELDIR)/include
 AM_CFLAGS=-fPIC -Wall
 LIBS=

Re: Fix --with-kernel for libnfnetlink

[Pablo Neira Ayuso]

Hi,

On Fri, Apr 21, 2006 at 09:21:58AM +0200, David Vogt wrote:
> 2006/4/20, Patrick McHardy <kaber@trash.net>:
> > David Vogt wrote:
> > > Amin Azez has helped me with some trouble concerning the compilation
> > > of libnfnetlink.
> > > The --with-kernel parameter for the configure script did not work as
> > > intended, so Amin has proposed the following changes that 1) look for
> > > the kernel sources 2) recognise --with-kernel parameter.
> >
> > Please change this to use --kernel as literal path as suggested
> > by Sven Koch.
> 
> Like this?
> 
> Index: configure.in
> ===================================================================
> --- configure.in	(revision 6583)
> +++ configure.in	(working copy)
> @@ -18,6 +18,35 @@
> 
> 
>  dnl--------------------------------
> +AC_DEFUN([NF_KERNEL_SOURCE],[
> +
> + if test "$with_kernel" = ""; then
> +   KERNEL="/lib/modules/`uname -r`/build"
> + else
> +   KERNEL="$with_kernel"
> + fi
> +
> + AC_MSG_CHECKING([for kernel headers in $KERNEL/include])
> + if test -r "$KERNEL/include/linux/config.h" ; then
> +   AC_SUBST(KERNELDIR,[$KERNEL])
> +   AC_MSG_RESULT([found])
> + else
> +   AC_MSG_ERROR([not found])
> + fi
> +
> +])
> +
> +AC_ARG_WITH(kernel,
> +              AC_HELP_STRING([--with-kernel=DIR],
> +                             [ Show location of kernel source.
> Default is to use uname -r and look in
> /lib/modules/KERNEL/build/include. ]),
> +              NF_KERNEL_SOURCE($with_kernel),NF_KERNEL_SOURCE())
> +
> +if test ! -z "$libdir"; then
> +  MODULE_DIR="\\\"$libdir/\\\""
> +  CFLAGS="$CFLAGS -DCONNTRACK_LIB_DIR=$MODULE_DIR"
> +fi
> +
> +
>  dnl--------------------------------

Why do you need this parameter? the netfilter libraries don't require
kernel headers anymore since they are already bundled in the package
provided. For example, see include/libnfnetlink/linux_nfnetlink.h. We
have had several problems with iptables and the kernel headers in the
past: compilation warnings, breakages... That is the reason why we
decided to do so.

On the other hand, autogen.sh automates the copy of these headers,
so you could choose them via KERNEL_DIR but you need some important
reason to do that.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: Fix --with-kernel for libnfnetlink

[Amin Azez]

Pablo Neira Ayuso wrote:

> Why do you need this parameter? the netfilter libraries don't require
> kernel headers anymore since they are already bundled in the package
> provided. For example, see include/libnfnetlink/linux_nfnetlink.h. We
> have had several problems with iptables and the kernel headers in the
> past: compilation warnings, breakages... That is the reason why we
> decided to do so.
> 
> On the other hand, autogen.sh automates the copy of these headers,
> so you could choose them via KERNEL_DIR but you need some important
> reason to do that.

I needed it because (at the time) I was working on netfilter and 
changing it. I was building multiple kernels with different modifications.

It's possibly only useful for developers (but this is netfilter-devel).

Sam

Re: Fix --with-kernel for libnfnetlink

[Pablo Neira Ayuso]

On Fri, Apr 21, 2006 at 01:48:41PM +0100, Amin Azez wrote:
> Pablo Neira Ayuso wrote:
> 
> >Why do you need this parameter? the netfilter libraries don't require
> >kernel headers anymore since they are already bundled in the package
> >provided. For example, see include/libnfnetlink/linux_nfnetlink.h. We
> >have had several problems with iptables and the kernel headers in the
> >past: compilation warnings, breakages... That is the reason why we
> >decided to do so.
> >
> >On the other hand, autogen.sh automates the copy of these headers,
> >so you could choose them via KERNEL_DIR but you need some important
> >reason to do that.
> 
> I needed it because (at the time) I was working on netfilter and 
> changing it. I was building multiple kernels with different modifications.
> 
> It's possibly only useful for developers (but this is netfilter-devel).

Still, why such thing would be useful?

I just noticed that this thread started from "Problem with compiling 
libnfnetlink". Could you check that you have /usr/include/asm/types.h
installed? it seems that your system doesn't find the definition of
__u32.

It's true that this is defined in a kernel header but such file is usually
provided by the linux-kernel-header package, that is the case of debian.
I think that is a reasonable requirement to compile libnfnetlink.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of 
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris 

Re: Fix --with-kernel for libnfnetlink

[Amin Azez]

Pablo Neira Ayuso wrote:
> On Fri, Apr 21, 2006 at 01:48:41PM +0100, Amin Azez wrote:
> 
>>Pablo Neira Ayuso wrote:
>>
>>
>>>Why do you need this parameter? the netfilter libraries don't require
>>>kernel headers anymore since they are already bundled in the package
>>>provided. For example, see include/libnfnetlink/linux_nfnetlink.h. We
>>>have had several problems with iptables and the kernel headers in the
>>>past: compilation warnings, breakages... That is the reason why we
>>>decided to do so.
>>>
>>>On the other hand, autogen.sh automates the copy of these headers,
>>>so you could choose them via KERNEL_DIR but you need some important
>>>reason to do that.
>>
>>I needed it because (at the time) I was working on netfilter and 
>>changing it. I was building multiple kernels with different modifications.
>>
>>It's possibly only useful for developers (but this is netfilter-devel).
> 
> 
> Still, why such thing would be useful?
> 
> I just noticed that this thread started from "Problem with compiling 
> libnfnetlink". Could you check that you have /usr/include/asm/types.h
> installed? it seems that your system doesn't find the definition of
> __u32.
> 
> It's true that this is defined in a kernel header but such file is usually
> provided by the linux-kernel-header package, that is the case of debian.
> I think that is a reasonable requirement to compile libnfnetlink.
> 


It's David Vogt who had the problem.
I supplied the --with-kernel autoconf code I wrote for the conntrack 
stuff when I autoconf-ified it for you.

I needed the code because I was modifiying conntrack and nfnetlink at 
the and changing some of the structs.

David, can you do the checks Pablo asks for?

While I recognize compilation warnings and breakages, I think that 
pretending that a linux-kernel-header package will always be up to date 
is just deferring the problem to some other time and place.

anyway... I'm fine as I can add this code when I need it and just ship 
my own source, but feel free to take up David's problem to see if 
another solution is preferred.

Sam

Re: Fix --with-kernel for libnfnetlink

[Amin Azez]

Sorry to bring this up again...

* Pablo Neira Ayuso wrote, On 21/04/06 12:09:
> Why do you need this parameter? the netfilter libraries don't require
> kernel headers anymore since they are already bundled in the package
> provided. For example, see include/libnfnetlink/linux_nfnetlink.h. We
> have had several problems with iptables and the kernel headers in the
> past: compilation warnings, breakages... That is the reason why we
> decided to do so.
> 
> On the other hand, autogen.sh automates the copy of these headers,
> so you could choose them via KERNEL_DIR but you need some important
> reason to do that.


Current (svn) autogen.sh is hard wired to use the currently booted kernel.

I'm all for not keeping a copy in the SVN tree, but why presume that the
one in the booted kernel is the one we want? Isn't this just another
reason to have --with-kernel back; as we are not copying old userland
so-called kernel header files?

Since my 2.6.11 work (which is booted) I'm now working towards 2.6.17,
and the differences are:

-#define NFNL_SUBSYS_CTHELPER           5
-#define NFNL_SUBSYS_COUNT              6
+#define NFNL_SUBSYS_COUNT              5

 #ifdef __KERNEL__

@@ -165,6 +164,7 @@
        __res;                                                          \
 })

+extern int nfnetlink_has_listeners(unsigned int group);


Which seem important; it is a mistake for autogen.sh to have copied the
file for the booted kernel.

I did wonder if libnfnetlink should use text labels instead of symbols,
and have the dynamic (or at least unpredicatbale) values fetched from
the kernel and stored as int's instead of constants in libnfnetlink

It would solve this problem.

Sam

quick fix Re: Fix --with-kernel for libnfnetlink

[Amin Azez]

I'm an idiot.
Sorry.

(Takes hammer for quick fix. Ouch. Fix complete).

Sam


* Amin Azez wrote, On 26/07/06 15:06:
> Sorry to bring this up again...
> 
> * Pablo Neira Ayuso wrote, On 21/04/06 12:09:
>> Why do you need this parameter? the netfilter libraries don't require
>> kernel headers anymore since they are already bundled in the package
>> provided. For example, see include/libnfnetlink/linux_nfnetlink.h. We
>> have had several problems with iptables and the kernel headers in the
>> past: compilation warnings, breakages... That is the reason why we
>> decided to do so.
>>
>> On the other hand, autogen.sh automates the copy of these headers,
>> so you could choose them via KERNEL_DIR but you need some important
>> reason to do that.
> 
> 
> Current (svn) autogen.sh is hard wired to use the currently booted kernel.
> 
> I'm all for not keeping a copy in the SVN tree, but why presume that the
> one in the booted kernel is the one we want? Isn't this just another
> reason to have --with-kernel back; as we are not copying old userland
> so-called kernel header files?
> 
> Since my 2.6.11 work (which is booted) I'm now working towards 2.6.17,
> and the differences are:
> 
> -#define NFNL_SUBSYS_CTHELPER           5
> -#define NFNL_SUBSYS_COUNT              6
> +#define NFNL_SUBSYS_COUNT              5
> 
>  #ifdef __KERNEL__
> 
> @@ -165,6 +164,7 @@
>         __res;                                                          \
>  })
> 
> +extern int nfnetlink_has_listeners(unsigned int group);
> 
> 
> Which seem important; it is a mistake for autogen.sh to have copied the
> file for the booted kernel.
> 
> I did wonder if libnfnetlink should use text labels instead of symbols,
> and have the dynamic (or at least unpredicatbale) values fetched from
> the kernel and stored as int's instead of constants in libnfnetlink
> 
> It would solve this problem.
> 
> Sam
> 
>