gcc-3.2 problems: i2c local vs. kernel headers

PATCH New Christian Hammers 5 participants 10 messages May 19, 2005

lore

Share & tools

lore

Christian Hammers

author

2005-05-19 06:23 UTC #0 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

Hello

I always got the following error when compiling lm_sensors-2.7.0:

Quoted 3 lines

gcc -DMODVERSIONS -include /lib/modules/2.4.20-bigvideo-1/build/include/linux/modversions.h -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/local/include -I/lib/modules/2.4.20-bigvideo-1/build/include -O2 -c kernel/busses/i2c-amd8111.c -o kernel/busses/i2c-amd8111.o
Quoted 1 line
	kernel/busses/i2c-amd8111.c:26:2: #error Your i2c is too old - i2c-2.7.0 or greater required!

This is a compile problem as the include files of 2.7.0 are in /usr/local/include/linux/. gcc-3.2.3 just puts /usr/local/include at the end of the list although it is first on the command line and the info page says the list is scanned left to right.

Quoted 7 lines

		GNU CPP version 3.2.3 20030316 (Debian prerelease) (cpplib)
	(i386 Linux/ELF)
	GNU C version 3.2.3 20030316 (Debian prerelease) (i386-linux)
		compiled by GNU C version 3.2.3 20030316 (Debian prerelease).
	ignoring nonexistent directory "/usr/i386-linux/include"
	ignoring duplicate directory "/usr/local/include"
	  as it is a non-system directory that duplicates a system directory

Quoted 8 lines

	#include "..." search starts here:
	#include <...> search starts here:
	 .
	 kernel/include
	 /usr/local/include
	 /usr/lib/gcc-lib/i386-linux/3.2.3/include
	 /usr/include
	 /lib/modules/2.4.20-bigvideo-1/build/include

As a fix I suggest:

# diff -u Makefile.orig Makefile
--- Makefile.orig       2003-03-19 18:20:38.000000000 +0100
+++ Makefile    2003-03-19 18:21:08.000000000 +0100
@@ -178,7 +178,7 @@
 # PROGCPPFLAGS/PROGCFLAGS is to create non-kernel object files (which are linked into executables).
 # ARCPPFLAGS/ARCFLAGS are used to create archive object files (static libraries).
 # LIBCPPFLAGS/LIBCFLAGS are for shared library objects.
-ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -I$(LINUX_HEADERS)
+ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -idirafter $(LINUX_HEADERS)
 ALL_CFLAGS := -O2

ifeq ($(DEBUG),1)

bye,

-christian-

Signature · 3 lines

 Big Misunderstandings #6398: The Titanic was not supposed to be
 unsinkable. The designer had a speech impediment. He said: "I have
 thith great unthinkable conthept ..."

Mark D. Studebaker

2005-05-19 06:23 UTC #1 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

that looks like an excellent solution. Thank you.

Quoted 54 lines · Christian Hammers

Hello
I always got the following error when compiling lm_sensors-2.7.0:
Quoted 4 lines
gcc -DMODVERSIONS -include /lib/modules/2.4.20-bigvideo-1/build/include/linux/modversions.h -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/local/include -I/lib/modules/2.4.20-bigvideo-1/build/include -O2 -c kernel/busses/i2c-amd8111.c -o kernel/busses/i2c-amd8111.o
Quoted 1 line
	kernel/busses/i2c-amd8111.c:26:2: #error Your i2c is too old - i2c-2.7.0 or greater required!
This is a compile problem as the include files of 2.7.0 are in /usr/local/include/linux/. gcc-3.2.3 just puts /usr/local/include at the end of the list although it is first on the command line and the info page says the list is scanned left to right.
Quoted 7 lines
		GNU CPP version 3.2.3 20030316 (Debian prerelease) (cpplib)
	(i386 Linux/ELF)
	GNU C version 3.2.3 20030316 (Debian prerelease) (i386-linux)
		compiled by GNU C version 3.2.3 20030316 (Debian prerelease).
	ignoring nonexistent directory "/usr/i386-linux/include"
	ignoring duplicate directory "/usr/local/include"
	  as it is a non-system directory that duplicates a system directory
Quoted 8 lines
	#include "..." search starts here:
	#include <...> search starts here:
	 .
	 kernel/include
	 /usr/local/include
	 /usr/lib/gcc-lib/i386-linux/3.2.3/include
	 /usr/include
	 /lib/modules/2.4.20-bigvideo-1/build/include
As a fix I suggest:
# diff -u Makefile.orig Makefile
Makefile 2003-03-19 18:21:08.000000000 +0100 renamed from Makefile.orig 2003-03-19 18:20:38.000000000 +0100 +1 -1
@@ -178,7 +178,7 @@
 # PROGCPPFLAGS/PROGCFLAGS is to create non-kernel object files (which are linked into executables).
 # ARCPPFLAGS/ARCFLAGS are used to create archive object files (static libraries).
 # LIBCPPFLAGS/LIBCFLAGS are for shared library objects.
-ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -I$(LINUX_HEADERS)
+ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -idirafter $(LINUX_HEADERS)
 ALL_CFLAGS := -O2 
 
 ifeq ($(DEBUG),1)
bye,
-christian-

Martin Dengler

2005-05-19 06:23 UTC #2 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

In reply to Christian Hammers

Christian's solution doesn't work perfectly with gcc 3.2.2. Since this is an earlier version than his I wouldn't expect a fix, but I thought I'd email in case this comes up again with other people and RedHat 9 (pulled my hair out for a while).

The problem seems to be that old headers from /usr/include/linux are being picked up in 3.2.2 and I couldn't find a way to get gcc to use the right ones. So I switched to gcc2.96 (on my Redhat 9, compat-gcc-7.3-2.96.118 provides /usr/bin/gcc296) in the Makefile and all worked fine.

I am using lm_sensors-2.7.0 on RH9. The error I got from gcc-3.2.2 after Christian's fix was:

----
[snip]
gcc -M -MG -D__SMP__ -DMODVERSIONS -include /lib/modules/2.4.20smp-lowlat-pre/build/include/linux/modversions.h -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/local/include -idirafter -I/lib/modules/2.4.20smp-lowlat-pre/build/include -O2

kernel/busses/i2c-ali1535.c | \
        sed -e 's@^\(.*\)\.o:@kernel/busses/i2c-ali1535.d
kernel/busses/i2c-ali1535.o: Makefile '`dirname
kernel/busses/i2c-ali1535.d`/Module.mk' @' > kernel/busses/i2c-ali1535.d
In file included from /usr/include/linux/fs.h:23,
                 from /usr/include/linux/capability.h:17,
                 from /usr/include/linux/binfmts.h:5,
                 from /usr/include/linux/sched.h:9,
                 from kernel/busses/i2c-ali1535.c:63:
/usr/include/linux/string.h:8:2: warning: #warning Using kernel header
in userland!
In file included from /usr/include/linux/bitops.h:69,
                 from /usr/include/asm/system.h:7,
                 from /usr/include/linux/sched.h:16,
                 from kernel/busses/i2c-ali1535.c:63:

/usr/include/asm/bitops.h:327:2: warning: #warning This includefile is not available on all architectures. /usr/include/asm/bitops.h:328:2: warning: #warning Using kernel headers in userspace: atomicity not guaranteed
make: *** No rule to make target linux/modules/53c700.ver', needed by kernel/chips/vt1211.d'. Stop.
----

This file appears to be a random (first in directory list order) file which exists in my kernel headers directory (/lib/modules/2.4.20smp-lowlat-pre/include/linux/modules/53c700.ver) but is not found by gcc. Doh...

Martin

Mark D. Studebaker wrote:
________________________________________________________________________
that looks like an excellent solution. Thank you.

Quoted 50 lines · Christian Hammers

Hello
I always got the following error when compiling lm_sensors-2.7.0:
Quoted 4 lines
gcc -DMODVERSIONS -include /lib/modules/2.4.20-bigvideo-1/build/include/linux/modversions.h -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/local/include -I/lib/modules/2.4.20-bigvideo-1/build/include -O2 -c kernel/busses/i2c-amd8111.c -o kernel/busses/i2c-amd8111.o
Quoted 1 line
	kernel/busses/i2c-amd8111.c:26:2: #error Your i2c is too old - i2c-2.7.0 or greater required!
This is a compile problem as the include files of 2.7.0 are in /usr/local/include/linux/. gcc-3.2.3 just puts /usr/local/include at the end of the list although it is first on the command line and the info page says the list is scanned left to right.
Quoted 7 lines
		GNU CPP version 3.2.3 20030316 (Debian prerelease) (cpplib)
	(i386 Linux/ELF)
	GNU C version 3.2.3 20030316 (Debian prerelease) (i386-linux)
		compiled by GNU C version 3.2.3 20030316 (Debian prerelease).
	ignoring nonexistent directory "/usr/i386-linux/include"
	ignoring duplicate directory "/usr/local/include"
	  as it is a non-system directory that duplicates a system directory
Quoted 8 lines
	#include "..." search starts here:
	#include <...> search starts here:
	 .
	 kernel/include
	 /usr/local/include
	 /usr/lib/gcc-lib/i386-linux/3.2.3/include
	 /usr/include
	 /lib/modules/2.4.20-bigvideo-1/build/include
As a fix I suggest:
# diff -u Makefile.orig Makefile
Makefile 2003-03-19 18:21:08.000000000 +0100 renamed from Makefile.orig 2003-03-19 18:20:38.000000000 +0100 +1 -1
@@ -178,7 +178,7 @@
 # PROGCPPFLAGS/PROGCFLAGS is to create non-kernel object files (which are linked into executables).
 # ARCPPFLAGS/ARCFLAGS are used to create archive object files (static libraries).
 # LIBCPPFLAGS/LIBCFLAGS are for shared library objects.
-ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -I$(LINUX_HEADERS)
+ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -idirafter $(LINUX_HEADERS)
 ALL_CFLAGS := -O2 
 
 ifeq ($(DEBUG),1)

Quoted 4 lines

bye,
-christian-

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030429/989c5d74/attachment.bin

Martin Dengler

2005-05-19 06:23 UTC #3 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

In reply to Christian Hammers

Well, I spoke too soon:

/lib/modules/2.4.20smp-lowlat-pre/kernel/drivers/i2c/i2c-amd756.o: The module you are trying to load (/lib/modules/2.4.20smp-lowlat-pre/kernel/drivers/i2c/i2c-amd756.o) is compiled with a gcc version 2 compiler, while the kernel you are running is compiled with a gcc version 3 compiler. This is known to not work.

Guess I need to keep working...

Quoted 104 lines · Martin Dengler

Christian's solution doesn't work perfectly with gcc 3.2.2. Since this is an earlier version than his I wouldn't expect a fix, but I thought I'd email in case this comes up again with other people and RedHat 9 (pulled my hair out for a while).
The problem seems to be that old headers from /usr/include/linux are being picked up in 3.2.2 and I couldn't find a way to get gcc to use the right ones. So I switched to gcc2.96 (on my Redhat 9, compat-gcc-7.3-2.96.118 provides /usr/bin/gcc296) in the Makefile and all worked fine.
I am using lm_sensors-2.7.0 on RH9. The error I got from gcc-3.2.2 after Christian's fix was:
----
[snip]
gcc -M -MG -D__SMP__ -DMODVERSIONS -include /lib/modules/2.4.20smp-lowlat-pre/build/include/linux/modversions.h
(quoted diff) +0 -3
-D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I.
-Ikernel/include -I/usr/local/include -idirafter
-I/lib/modules/2.4.20smp-lowlat-pre/build/include -O2 
kernel/busses/i2c-ali1535.c | \
        sed -e 's@^$.*$\.o:@kernel/busses/i2c-ali1535.d
kernel/busses/i2c-ali1535.o: Makefile '`dirname
kernel/busses/i2c-ali1535.d`/Module.mk' @' > kernel/busses/i2c-ali1535.d
In file included from /usr/include/linux/fs.h:23,
                 from /usr/include/linux/capability.h:17,
                 from /usr/include/linux/binfmts.h:5,
                 from /usr/include/linux/sched.h:9,
                 from kernel/busses/i2c-ali1535.c:63:
/usr/include/linux/string.h:8:2: warning: #warning Using kernel header
in userland!
In file included from /usr/include/linux/bitops.h:69,
                 from /usr/include/asm/system.h:7,
                 from /usr/include/linux/sched.h:16,
                 from kernel/busses/i2c-ali1535.c:63:
/usr/include/asm/bitops.h:327:2: warning: #warning This includefile is not available on all architectures. /usr/include/asm/bitops.h:328:2: warning: #warning Using kernel headers in userspace: atomicity not guaranteed
make: *** No rule to make target linux/modules/53c700.ver', needed by kernel/chips/vt1211.d'. Stop.
----
This file appears to be a random (first in directory list order) file which exists in my kernel headers directory (/lib/modules/2.4.20smp-lowlat-pre/include/linux/modules/53c700.ver) but is not found by gcc. Doh...
Martin
Mark D. Studebaker wrote:
________________________________________________________________________
that looks like an excellent solution. Thank you.
Quoted 46 lines · Christian Hammers
Hello
I always got the following error when compiling lm_sensors-2.7.0:
Quoted 4 lines
gcc -DMODVERSIONS -include /lib/modules/2.4.20-bigvideo-1/build/include/linux/modversions.h -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/local/include -I/lib/modules/2.4.20-bigvideo-1/build/include -O2 -c kernel/busses/i2c-amd8111.c -o kernel/busses/i2c-amd8111.o
Quoted 1 line
	kernel/busses/i2c-amd8111.c:26:2: #error Your i2c is too old - i2c-2.7.0 or greater required!
This is a compile problem as the include files of 2.7.0 are in /usr/local/include/linux/. gcc-3.2.3 just puts /usr/local/include at the end of the list although it is first on the command line and the info page says the list is scanned left to right.
Quoted 7 lines
		GNU CPP version 3.2.3 20030316 (Debian prerelease) (cpplib)
	(i386 Linux/ELF)
	GNU C version 3.2.3 20030316 (Debian prerelease) (i386-linux)
		compiled by GNU C version 3.2.3 20030316 (Debian prerelease).
	ignoring nonexistent directory "/usr/i386-linux/include"
	ignoring duplicate directory "/usr/local/include"
	  as it is a non-system directory that duplicates a system directory
Quoted 8 lines
	#include "..." search starts here:
	#include <...> search starts here:
	 .
	 kernel/include
	 /usr/local/include
	 /usr/lib/gcc-lib/i386-linux/3.2.3/include
	 /usr/include
	 /lib/modules/2.4.20-bigvideo-1/build/include
As a fix I suggest:
# diff -u Makefile.orig Makefile
Makefile 2003-03-19 18:21:08.000000000 +0100 renamed from Makefile.orig 2003-03-19 18:20:38.000000000 +0100 +1 -1
@@ -178,7 +178,7 @@
 # PROGCPPFLAGS/PROGCFLAGS is to create non-kernel object files (which are linked into executables).
 # ARCPPFLAGS/ARCFLAGS are used to create archive object files (static libraries).
 # LIBCPPFLAGS/LIBCFLAGS are for shared library objects.
-ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -I$(LINUX_HEADERS)
+ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -idirafter $(LINUX_HEADERS)
 ALL_CFLAGS := -O2 
 

Quoted 9 lines

Quoted 8 lines
Makefile 2003-03-19 18:21:08.000000000 +0100 renamed from Makefile.orig 2003-03-19 18:20:38.000000000 +0100 +0 -0
 ifeq ($(DEBUG),1)
bye,
-christian-

Martin Dengler

2005-05-19 06:23 UTC #4 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

In reply to Christian Hammers

Jean,

Thanks for the excellent advice. The changing of
/usr/include/{asm,linux} did work for me! For RedHat 9 people though, those two directories are provided by the RPM glibc-kernheaders, upon which gcc depends. So there was no clean & simple way to install/remove packages to remove the two dirs. I temporarily moved them, symlinked my kernel build in, and compiled things. Worked the first time.

As an aside, I suppose it's bad form by either glibc-kernheaders or
gcc 3.2.2 to get anyone into this situation. Does anyone know if gcc 3.2.3 behaves better or it was the lack of RedHat packages writing to /usr/include/{asm,linux} that enabled Christian's solution to work?

Martin

Quoted 27 lines · Jean Delvare

Quoted 10 lines
Christian's solution doesn't work perfectly with gcc 3.2.2. Since this is an earlier version than his I wouldn't expect a fix, but I thought I'd email in case this comes up again with other people and RedHat 9(pulled my hair out for a while).
The problem seems to be that old headers from /usr/include/linux are being picked up in 3.2.2 and I couldn't find a way to get gcc to use the right ones. So I switched to gcc2.96 (on my Redhat 9, compat-gcc-7.3-2.96.118 provides /usr/bin/gcc296) in the Makefile and all worked fine.
I had similar problems as I switched to Slackware 9.0. The main problem is that I first asked the distribution to install kernel headers (as a package), and then installed and compiled my own kernel from sources. Then, as I tried to compile i2c and lm_sensors for this new kernel, headers were a complete mess. The clean solution I used is:
1* Remove the kernel headers package. This package installed all headers directly in /usr/include, where non-kernel headers also live. These files aren't needed once you have real kernel sources available.
2* Create the following symlinks (these are *directories*):
/usr/include/asm -> /usr/src/linux/include/asm /usr/include/linux -> /usr/src/linux/include/linux
This of course assume that you have a complete kernel source tree at /usr/src/linux.

Quoted 5 lines

After that, everything compiled smoothly, providing Christian's fix is *also* used. I don't really know why it works (since the change isn't supposed to actually change anything), but I know it did.
I hope it'll work for you as it worked for me ;)

Martin Dengler

2005-05-19 06:23 UTC #5 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

In reply to Christian Hammers

So who's wrong?

Quoted 24 lines · Mark M. Hoffman

Quoted 10 lines · Jean Delvare
I had similar problems as I switched to Slackware 9.0. The main problem is that I first asked the distribution to install kernel headers (as a package), and then installed and compiled my own kernel from sources. Then, as I tried to compile i2c and lm_sensors for this new kernel, headers were a complete mess. The clean solution I used is:
1* Remove the kernel headers package. This package installed all headers directly in /usr/include, where non-kernel headers also live. These files aren't needed once you have real kernel sources available.
Quoted 5 lines
2* Create the following symlinks (these are *directories*):
/usr/include/asm -> /usr/src/linux/include/asm /usr/include/linux -> /usr/src/linux/include/linux
This of course assume that you have a complete kernel source tree at /usr/src/linux.
Please read this:
http://www.tldp.org/LDP/lfs/html/chapter06/kernel.html#AEN2385
Slackware and RedHat (glibc-kernheaders) are doing the right thing.

Quoted 8 lines

Quoted 3 lines
After that, everything compiled smoothly, providing Christian's fix is *also* used. I don't really know why it works (since the change isn't supposed to actually change anything), but I know it did.
I haven't looked at this fix yet... but I will when I get the chance. I have a RedHat 9 here I can try.
Regards,

Jean Delvare

2005-05-19 06:23 UTC #6 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

In reply to Christian Hammers

Quoted 11 lines

Christian's solution doesn't work perfectly with gcc 3.2.2. Since this is an earlier version than his I wouldn't expect a fix, but I thought I'd email in case this comes up again with other people and RedHat 9(pulled my hair out for a while).
The problem seems to be that old headers from /usr/include/linux are being picked up in 3.2.2 and I couldn't find a way to get gcc to use the right ones. So I switched to gcc2.96 (on my Redhat 9, compat-gcc-7.3-2.96.118 provides /usr/bin/gcc296) in the Makefile and all worked fine.

I had similar problems as I switched to Slackware 9.0. The main problem is that I first asked the distribution to install kernel headers (as a package), and then installed and compiled my own kernel from sources. Then, as I tried to compile i2c and lm_sensors for this new kernel, headers were a complete mess. The clean solution I used is:

1* Remove the kernel headers package. This package installed all headers directly in /usr/include, where non-kernel headers also live. These files aren't needed once you have real kernel sources available.

2* Create the following symlinks (these are *directories*):
/usr/include/asm -> /usr/src/linux/include/asm /usr/include/linux -> /usr/src/linux/include/linux
This of course assume that you have a complete kernel source tree at /usr/src/linux.

After that, everything compiled smoothly, providing Christian's fix is *also* used. I don't really know why it works (since the change isn't supposed to actually change anything), but I know it did.

I hope it'll work for you as it worked for me ;)

Signature · 2 lines

Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Mark M. Hoffman

2005-05-19 06:23 UTC #7 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

In reply to Christian Hammers

Quoted 10 lines · Jean Delvare

I had similar problems as I switched to Slackware 9.0. The main problem is that I first asked the distribution to install kernel headers (as a package), and then installed and compiled my own kernel from sources. Then, as I tried to compile i2c and lm_sensors for this new kernel, headers were a complete mess. The clean solution I used is:
1* Remove the kernel headers package. This package installed all headers directly in /usr/include, where non-kernel headers also live. These files aren't needed once you have real kernel sources available.

Quoted 5 lines

2* Create the following symlinks (these are *directories*):
/usr/include/asm -> /usr/src/linux/include/asm /usr/include/linux -> /usr/src/linux/include/linux
This of course assume that you have a complete kernel source tree at /usr/src/linux.

Please read this:

http://www.tldp.org/LDP/lfs/html/chapter06/kernel.html#AEN2385

Slackware and RedHat (glibc-kernheaders) are doing the right thing.

Quoted 3 lines

After that, everything compiled smoothly, providing Christian's fix is *also* used. I don't really know why it works (since the change isn't supposed to actually change anything), but I know it did.

I haven't looked at this fix yet... but I will when I get the chance. I have a RedHat 9 here I can try.

Regards,

Signature · 2 lines

Mark M. Hoffman
[email protected]

Mark M. Hoffman

2005-05-19 06:23 UTC #8 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

In reply to Christian Hammers

This is a long message, sorry...

Quoted 18 lines · Mark M. Hoffman

Quoted 10 lines · Jean Delvare
I had similar problems as I switched to Slackware 9.0. The main problem is that I first asked the distribution to install kernel headers (as a package), and then installed and compiled my own kernel from sources. Then, as I tried to compile i2c and lm_sensors for this new kernel, headers were a complete mess. The clean solution I used is:
1* Remove the kernel headers package. This package installed all headers directly in /usr/include, where non-kernel headers also live. These files aren't needed once you have real kernel sources available.
Quoted 5 lines
2* Create the following symlinks (these are *directories*):
/usr/include/asm -> /usr/src/linux/include/asm /usr/include/linux -> /usr/src/linux/include/linux
This of course assume that you have a complete kernel source tree at /usr/src/linux.

Quoted 6 lines

Please read this:
http://www.tldp.org/LDP/lfs/html/chapter06/kernel.html#AEN2385
Slackware and RedHat (glibc-kernheaders) are doing the right thing.

When compiling a program, you want the system headers to match those which were used to compile your glibc, *not* the currently running kernel itself. So, the RH package glibc-kernheaders installs the headers into /usr/include/{asm,linux} which were used to build glibc.

After compiling and installing i2c and lm_sensors, those headers go under /usr/local/include. The default include order puts this ahead of /usr/include so that's ok too. You installed a new libsensors so you want programs to compile with the new (sensors) headers.

The /usr/include/{asm,linux} links are a bad idea (so says Linus in the above reference) *unless* you also recompile *all* of your system libraries to match - something you are unlikely to do every time you compile a new kernel.

But, the sensors modules themselves need to be compiled against headers from the kernel with which you expect them to run (this is true for most kernel modules.) Ultimately, we want the include order to look like this for lm_sensors2 kernel modules:

	.                    (from lm_sensors2)
	kernel/include       (from lm_sensors2)
	/usr/local/include   (from i2c)
	$(LINUX_HEADERS)     (target kernel, e.g. ~/src/linux-2.4.21)

<other GCC includes>
/usr/include

This is accomplished with older GCCs by specifying -I/usr/local/include before -I$(LINUX_HEADERS). But, newer GCC *ignores* the -I/usr/local/include argument (because it's already considered a system include directory). So newer GCC produces this instead:

	.
	kernel/include
	$(LINUX_HEADERS)     (target kernel)
	/usr/local/include   (from i2c)
	<other GCC includes>
	/usr/include

This is a problem, because we need the new i2c headers in /usr/local/include to trump the older ones in $(LINUX_HEADERS). Christian's patch leads to this:

	.
	kernel/include
	/usr/local/include   (from i2c)
	<other GCC includes>
	/usr/include
	$(LINUX_HEADERS)     (target kernel)

That's still wrong, because we're going to pick up old kernel headers from /usr/include while compiling the kernel modules. Now you see why Jean's method works for lm_sensors2... because he's wacking /usr/include and replacing it with $(LINUX_HEADERS) - which seems to work for lm_sensors2 but is wrong for just about every other thing you would want to compile. (Again, see that web reference above.)

So after all that, here's a fix as diff from 2.7.0. It produces the correct include order (first of 3 above). This works fine with stock RedHat 9, keeping glibc-kernheaders intact. I tested with RedHat 8.0 too.

Jean, could you please test this with Slackware? Any other comments before I check it in?

Index: Makefile
=================================RCS file: /home/cvs/lm_sensors2/Makefile,v retrieving revision 1.60
diff -r1.60 Makefile
181c181
< ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS) -I$(LINUX_HEADERS)
---

Quoted 1 line

ALL_CPPFLAGS := -I. -Ikernel/include -isystem $(I2C_HEADERS) -isystem $(LINUX_HEADERS)

Regards,

Signature · 2 lines

Mark M. Hoffman
[email protected]

Jean Delvare

2005-05-19 06:23 UTC #9 lore raw

PATCH 1/1 gcc-3.2 problems: i2c local vs. kernel headers

In reply to Christian Hammers

Quoted 5 lines

Please read this:
http://www.tldp.org/LDP/lfs/html/chapter06/kernel.html#AEN2385

Quoted 8 lines

Slackware and RedHat (glibc-kernheaders) are doing the right thing.
When compiling a program, you want the system headers to match those which were used to compile your glibc, *not* the currently running kernel itself. So, the RH package glibc-kernheaders installs the headers into /usr/include/{asm,linux} which were used to build glibc.

I find Linus' speech particularly unclear. He seems to keep the "original" headers in /usr/src/linux, whereas we are discussing about having them in /usr/include *instead* of having symlinks there, pointing to *newer* headers at /usr/src/linux. I think I get the main idea though (that is, one should use the original headers unless he/she is building kernel modules.

Quoted 7 lines

So after all that, here's a fix as diff from 2.7.0. It produces the correct include order (first of 3 above). This works fine with stock RedHat 9, keeping glibc-kernheaders intact. I tested with RedHat 8.0 too.
Jean, could you please test this with Slackware? Any other comments before I check it in?

Sorry for the delay. I just tested your patch on Slackware (almost) 8.1 (with the symlinks trick) and 9.0 (with copied kernel headers). It works well for both. Great job :)

It's unrelated with your patch, but I noticed new warnings, probably due to the fact I'm using gcc 3.2.2.

lib/data.c: In function `sensors_parse_chip_name':
lib/data.c:117: warning: deprecated use of label at end of compound statement
lib/data.c:151: warning: deprecated use of label at end of compound statement

Should we fix them? I could take care of this.

Signature · 2 lines

Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/