[Cluster-devel] [PATCH] for a header-file-cannot-found building error

[Cluster-devel] [PATCH] for a header-file-cannot-found building error

[Denis Cheng]

the -idirafter used as a backend including path for header files, but the original style
didn't work, pick a specific gcc command from the making process:

gcc -Wall  -g -I. -O2 -idirafter /usr/src/linux-2.6.21.7/include/linux -I//usr/include \
        -I../config -I../../cman/lib -I../include/ -I../lib/ -c -o plock.o plock.c
plock.c:37:34: linux/lock_dlm_plock.h: No such file or directory

just because plock.c needs a header file <linux/lock_dlm_plock.h>, this could work:

gcc -Wall  -g -I. -O2 -idirafter /usr/src/linux-2.6.21.7/include -I//usr/include \
        -I../config -I../../cman/lib -I../include/ -I../lib/ -c -o plock.o plock.c

--- ./cluster-2.00.00/group/dlm_controld/Makefile.orig	2006-08-11 23:18:15.000000000 +0800
+++ ./cluster-2.00.00/group/dlm_controld/Makefile	2007-08-15 11:02:47.000000000 +0800
@@ -17,7 +17,7 @@
 
 CFLAGS+= -g -I${incdir} -I${top_srcdir}/config
 
-CFLAGS+= -idirafter ${KERNEL_SRC}/include/linux \
+CFLAGS+= -idirafter ${KERNEL_SRC}/include \
 	-I../../group/lib/ \
 	-I../../ccs/lib/ \
 	-I../../cman/lib/ \

--- ./cluster-2.00.00/group/gfs_controld/Makefile.orig	2006-08-11 23:18:15.000000000 +0800
+++ ./cluster-2.00.00/group/gfs_controld/Makefile	2007-08-15 11:02:38.000000000 +0800
@@ -16,7 +16,7 @@
 include ${top_srcdir}/make/defines.mk
 
 CFLAGS+= -g -I. -O2 \
-	-idirafter ${KERNEL_SRC}/include/linux \
+	-idirafter ${KERNEL_SRC}/include \
 	-I${incdir} \
 	-I${top_srcdir}/config \
 	-I../../cman/lib \

[Cluster-devel] [PATCH] for a header-file-cannot-found building error

[David Teigland]

On Wed, Aug 15, 2007 at 11:27:01AM +0800, Denis Cheng wrote:
> the -idirafter used as a backend including path for header files, but
> the original style didn't work, pick a specific gcc command from the
> making process:
> 
> gcc -Wall  -g -I. -O2 -idirafter /usr/src/linux-2.6.21.7/include/linux
> -I//usr/include \ -I../config -I../../cman/lib -I../include/ -I../lib/
> -c -o plock.o plock.c plock.c:37:34: linux/lock_dlm_plock.h: No such
> file or directory
> 
> just because plock.c needs a header file <linux/lock_dlm_plock.h>, this
> could work:

I believe that the correct solution is to install the necessary kernel
headers into /usr/include/linux/ prior to building cluster.  This
usually means doing something like this:
  cd /usr/src/linux
  make headers_install
  cp usr/include/linux/dlm* /usr/include/linux/
  cp usr/include/linux/gfs* /usr/include/linux/
  cp usr/include/linux/lock_dlm_plock.h /usr/include/linux/
  cp usr/include/linux/lm_interface.h /usr/include/linux/
  (that's all I can think of at the moment)
 
Dave
 

[Cluster-devel] [PATCH] for a header-file-cannot-found building error

[程任全]

On 8/16/07, David Teigland <teigland@redhat.com> wrote:
> On Wed, Aug 15, 2007 at 11:27:01AM +0800, Denis Cheng wrote:
> > the -idirafter used as a backend including path for header files, but
> > the original style didn't work, pick a specific gcc command from the
> > making process:
> >
> > gcc -Wall  -g -I. -O2 -idirafter /usr/src/linux-2.6.21.7/include/linux
> > -I//usr/include \ -I../config -I../../cman/lib -I../include/ -I../lib/
> > -c -o plock.o plock.c plock.c:37:34: linux/lock_dlm_plock.h: No such
> > file or directory
> >
> > just because plock.c needs a header file <linux/lock_dlm_plock.h>, this
> > could work:
>
> I believe that the correct solution is to install the necessary kernel
> headers into /usr/include/linux/ prior to building cluster.  This
> usually means doing something like this:
>   cd /usr/src/linux
>   make headers_install
>   cp usr/include/linux/dlm* /usr/include/linux/
>   cp usr/include/linux/gfs* /usr/include/linux/
>   cp usr/include/linux/lock_dlm_plock.h /usr/include/linux/
>   cp usr/include/linux/lm_interface.h /usr/include/linux/
>   (that's all I can think of at the moment)
the raw kernel headers by make headers_install wourld generate siding
effect to other compiling processes, we should use linux headers under
/usr/include from Linux-Libc-Headers Project instead:
http://linuxfromscratch.org/pipermail/faq/2004-July/000159.html

However: the current style doesn't work:
	-idirafter /usr/src/linux-2.6.21.7/include/linux
and it does work if changed to this:
	-idirafter /usr/src/linux-2.6.21.7/include

So, if you use the raw kernel headers from the running kernel, you
don't need -idirafter parameter; or if you need it, the current is
wrong.

>
> Dave
>
>


-- 
Denis Cheng
Linux Application Developer

"One of my most productive days was throwing away 1000 lines of code."
 - Ken Thompson.

[Cluster-devel] [PATCH] for a header-file-cannot-found building error

[Fabio Massimo Di Nitto]

David Teigland wrote:

> 
> I believe that the correct solution is to install the necessary kernel
> headers into /usr/include/linux/ prior to building cluster.  This
> usually means doing something like this:
>   cd /usr/src/linux
>   make headers_install
>   cp usr/include/linux/dlm* /usr/include/linux/
>   cp usr/include/linux/gfs* /usr/include/linux/
>   cp usr/include/linux/lock_dlm_plock.h /usr/include/linux/
>   cp usr/include/linux/lm_interface.h /usr/include/linux/
>   (that's all I can think of at the moment)
>  
> Dave
>  

I did look into this a bit more and we need to make some kind of a decision here.

If we expect people building the cluster to install the headers with
headers_install then we can basically remove all the references to KERNEL_SRC in
all userland and everything will keep building just fine.

If we want to allow people to build the cluster with an outside kernel then we
need to fix or change the dirafter and change the Makefile's that use KERNEL_SRC
to be all consistent in the same way.

Given that we need KERNEL_SRC defined for the kernel modules that we carry
around in the CVS tree, I would suggest to go for the latter solution and allow
our users to build whatever they need.

I have patches ready for both cases so David, please let me know what you guys
would prefer.

Fabio

-- 
I'm going to make him an offer he can't refuse.

[Cluster-devel] [PATCH] for a header-file-cannot-found building error

[David Teigland]

On Sun, Aug 19, 2007 at 07:32:57AM +0200, Fabio Massimo Di Nitto wrote:
> David Teigland wrote:
> 
> > 
> > I believe that the correct solution is to install the necessary kernel
> > headers into /usr/include/linux/ prior to building cluster.  This
> > usually means doing something like this:
> >   cd /usr/src/linux
> >   make headers_install
> >   cp usr/include/linux/dlm* /usr/include/linux/
> >   cp usr/include/linux/gfs* /usr/include/linux/
> >   cp usr/include/linux/lock_dlm_plock.h /usr/include/linux/
> >   cp usr/include/linux/lm_interface.h /usr/include/linux/
> >   (that's all I can think of at the moment)
> >  
> > Dave
> >  
> 
> I did look into this a bit more and we need to make some kind of a
> decision here.
> 
> If we expect people building the cluster to install the headers with
> headers_install then we can basically remove all the references to
> KERNEL_SRC in all userland and everything will keep building just fine.
> 
> If we want to allow people to build the cluster with an outside kernel
> then we need to fix or change the dirafter and change the Makefile's
> that use KERNEL_SRC to be all consistent in the same way.
> 
> Given that we need KERNEL_SRC defined for the kernel modules that we
> carry around in the CVS tree, I would suggest to go for the latter
> solution and allow our users to build whatever they need.

Yep, I agree

[Cluster-devel] [PATCH] for a header-file-cannot-found building error

[Fabio Massimo Di Nitto]

David Teigland wrote:

>> If we want to allow people to build the cluster with an outside kernel
>> then we need to fix or change the dirafter and change the Makefile's
>> that use KERNEL_SRC to be all consistent in the same way.
>>
>> Given that we need KERNEL_SRC defined for the kernel modules that we
>> carry around in the CVS tree, I would suggest to go for the latter
>> solution and allow our users to build whatever they need.
> 
> Yep, I agree

I committed the fix in CVS HEAD. You might also notice that I had to remove
-idirafter and switch to a more classic -I because on some old versions of gcc
it does not behave like we expect in the most recent ones and it was failing to
build.

Fabio

-- 
I'm going to make him an offer he can't refuse.