Skip to contentSkip to conversation

for a header-file-cannot-found building error

PATCH New Denis Cheng 4 participants 6 messages Aug 15, 2007 – Aug 21, 2007

lore
Share & tools
lore

Denis Cheng

author
#0 lore raw

PATCH 1/1 for a header-file-cannot-found building error

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 renamed from cluster-2.00.00/group/dlm_controld/Makefile.orig +1 -1
@@ -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 renamed from cluster-2.00.00/group/gfs_controld/Makefile.orig +1 -1
@@ -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 \
#1 lore raw

PATCH 1/1 for a header-file-cannot-found building error

Quoted 11 lines · 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

(quoted diff) +0 -2
-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

#2 lore raw

PATCH 1/1 for a header-file-cannot-found building error

Quoted 10 lines · David Teigland
Quoted 9 lines · 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

(quoted diff) +0 -2
-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

Quoted 13 lines
Quoted 2 lines

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.

Quoted 4 lines

Dave

Signature · 5 lines
Denis Cheng
Linux Application Developer

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

PATCH 1/1 for a header-file-cannot-found building error

In reply to David Teigland
Quoted 12 lines · David Teigland

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)

Quoted 2 lines

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

Signature · 1 line
I'm going to make him an offer he can't refuse.
#4 lore raw

PATCH 1/1 for a header-file-cannot-found building error

Quoted 24 lines · Fabio Massimo Di Nitto
Quoted 12 lines · David Teigland

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)

Quoted 2 lines

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.

Quoted 7 lines

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

#5 lore raw

PATCH 1/1 for a header-file-cannot-found building error

Quoted 9 lines · David Teigland
Quoted 7 lines

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

Signature · 1 line
I'm going to make him an offer he can't refuse.