I run Gentoo (up-to-date and allowing ~x86) with my own hand-made kernel (under /usr/src/linux). lm_sensors-2.7.0 pulls i2c-2.7.0 which gets installed fine, but the lm_sensors build fails like this: gcc -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/include -I/lib/modules/2.4.21-pre4/build/include -O2 -c kernel/busses/i2c-amd756.c -o kernel/busses/i2c-amd756.o gcc -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/include -I/lib/modules/2.4.21-pre4/build/include -O2 -c kernel/busses/i2c-amd8111.c -o kernel/busses/i2c-amd8111.o kernel/busses/i2c-amd8111.c:25:2: #error Your i2c is too old - i2c-2.7.0 or greater required! kernel/busses/i2c-amd8111.c: In function `amd8111_access': kernel/busses/i2c-amd8111.c:238: `I2C_CLIENT_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:238: (Each undeclared identifier is reported only once kernel/busses/i2c-amd8111.c:238: for each function it appears in.) kernel/busses/i2c-amd8111.c:298: `I2C_SMBUS_BLOCK_PROC_CALL' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:309: `I2C_SMBUS_WORD_DATA_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:310: `I2C_SMBUS_BLOCK_DATA_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:311: `I2C_SMBUS_PROC_CALL_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:312: `I2C_SMBUS_BLOCK_PROC_CALL_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c: In function `amd8111_func': kernel/busses/i2c-amd8111.c:385: `I2C_FUNC_SMBUS_BLOCK_PROC_CALL' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:386: `I2C_FUNC_SMBUS_HWPEC_CALC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c: In function `amd8111_probe': kernel/busses/i2c-amd8111.c:426: `I2C_HW_SMBUS_AMD8111' undeclared (first use in this function) make: *** [kernel/busses/i2c-amd8111.o] Error 1 It seems that the lm_sensors build picks up the i2c header files that are supplied with the kernel (instead of thos provided by the i2c package). Tinkering with the -I paths didn't quite solve it. Reproducible: Always Steps to Reproduce: emerge lm_sensors Actual Results: gcc -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/include -I/lib/modules/2.4.21-pre4/build/include -O2 -c kernel/busses/i2c-amd756.c -o kernel/busses/i2c-amd756.o gcc -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer -I. -Ikernel/include -I/usr/include -I/lib/modules/2.4.21-pre4/build/include -O2 -c kernel/busses/i2c-amd8111.c -o kernel/busses/i2c-amd8111.o kernel/busses/i2c-amd8111.c:25:2: #error Your i2c is too old - i2c-2.7.0 or greater required! kernel/busses/i2c-amd8111.c: In function `amd8111_access': kernel/busses/i2c-amd8111.c:238: `I2C_CLIENT_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:238: (Each undeclared identifier is reported only once kernel/busses/i2c-amd8111.c:238: for each function it appears in.) kernel/busses/i2c-amd8111.c:298: `I2C_SMBUS_BLOCK_PROC_CALL' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:309: `I2C_SMBUS_WORD_DATA_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:310: `I2C_SMBUS_BLOCK_DATA_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:311: `I2C_SMBUS_PROC_CALL_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:312: `I2C_SMBUS_BLOCK_PROC_CALL_PEC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c: In function `amd8111_func': kernel/busses/i2c-amd8111.c:385: `I2C_FUNC_SMBUS_BLOCK_PROC_CALL' undeclared (first use in this function) kernel/busses/i2c-amd8111.c:386: `I2C_FUNC_SMBUS_HWPEC_CALC' undeclared (first use in this function) kernel/busses/i2c-amd8111.c: In function `amd8111_probe': kernel/busses/i2c-amd8111.c:426: `I2C_HW_SMBUS_AMD8111' undeclared (first use in this function) make: *** [kernel/busses/i2c-amd8111.o] Error 1 Expected Results: Emerged lm_sensors-2.7.0 Portage 2.0.47-r8 (default-x86-1.4, gcc-3.2.2, glibc-2.3.2_pre1-r0) ================================================================= System uname: 2.4.21-pre4 i686 AMD Athlon(tm) processor GENTOO_MIRRORS="http://ftp.freenet.de/pub/ftp.ibiblio.org/pub/Linux/distributions/gentoo ftp://ftp.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss 3dnow apm avi crypt cups encode gif jpeg libg++ mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gtkhtml gdbm berkdb slang readline tetex aalib bonobo svga ggi tcltk java guile sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis motif opengl mozilla snmp cdr scanner X gtk gnome -alsa -arts -kde -qt gtk2 dvd" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O2 -pipe" CXXFLAGS="-march=athlon-tbird -O2 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j1" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
I confirmed this. Even worse, it doesnt need to be a custom kernel. I cant emerge it with openmosix-sources installed.
I had the same problem with the ck-sources version 2.4.20-r4. The solution is to patch to Makefile as stated in the bugreport on the site of lm_sensors. See http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1189 for more info. I attached a changed ebuild for lm_sensors to do all this.
Created attachment 10371 [details] A patched ebuild for lm_sensors
Now get a very irritating error msg: # modprobe via686a /lib/modules/2.4.21-pre7/misc/via686a.o: kernel-module version mismatch /lib/modules/2.4.21-pre7/misc/via686a.o was compiled for kernel version 2.4.19 while this kernel is version 2.4.21-pre7. /lib/modules/2.4.21-pre7/misc/via686a.o: insmod /lib/modules/2.4.21-pre7/misc/via686a.o failed /lib/modules/2.4.21-pre7/misc/via686a.o: insmod via686a failed Yes, this is definetly the module that was installed by emerge - but how did it get to think I was using 2.4.19? That kernel source isn't even on my harddisk!
Thus I remerged i2c - to no avail. It still thinks it was compiled with 2.4.19
The ebuild posted above compiles with vanilla linux-2.4.21-rc1. via686a.o *still* thinks it was compiled with 2.4.19.
If it's thinking it's 2.4.119, it's using linux-headers instead of the kernel's headers.
Right, the compile errors presented with the bug report happens because i2c / lm_sensors are using old i2c headers in /usr/include/linux/. Just copy over the i2c headers from the 2.7.0 package and all will be well. I don't quite know why it's not using its own i2c headers though. Also, I can confirm the ptrace patch in 2.4.20-gentoo-r5 completely buggers i2c and lm_sensors (both 2.6.5 and 2.70!!). Use vanilla-sources-2.4.20 for now. HTH.
Just emerging the most-up-to-date i2c (which, according to epm contains a bunch of .h files in /usr/include/linux), then emerging lm-sensors as shipped with portage: same error as initially. then trying to merge the attached ebuild from Arno yields this when using sensors-detect: Load `i2c-viapro' (say NO if built into your kernel)? (YES/no): /lib/modules/2.4.21-rc1/misc/i2c-viapro.o: kernel-module version mismatch /lib/modules/2.4.21-rc1/misc/i2c-viapro.o was compiled for kernel version 2.4.19 while this kernel is version 2.4.21-rc1. /lib/modules/2.4.21-rc1/misc/i2c-viapro.o: insmod /lib/modules/2.4.21-rc1/misc/i2c-viapro.o failed /lib/modules/2.4.21-rc1/misc/i2c-viapro.o: insmod i2c-viapro failed Loading failed... skipping. So I unmerged linux-headers and copied /usr/src/linux/include/* to /usr/include/linux (wouldn't a softlink be better?) Result: works like a charm.
Oh I forgot... linux-headers was on my system as a dependency of something else... I just don't know what because there's no reverse-dependency-checking in portage.
....result: 2/3 of the updates won't compile just great.
reinstalled linux-headers 2.4.19. Let's see how fucked up it is next time I need to compile lm_sensors.
Okay, after fiddling with various versions of the kernel and headers, I've found this recipe to work - for me: - Keep linux-headers-2.4.19 installed, it will get pulled as a dep for baselayout for example. - Compile a new kernel, symlinked under /usr/src/linux - Boot that kernel, the lm-sensors Makefile uses uname to find some headerfiles. Not particularly bright, but not at my option to change. - Copy relevant header-files like this: epm -ql linux-headers|awk '{print $1,$1}'| sed -e \ 's:^/usr/include/:/usr/src/linux/include/:g'|awk '{print "cp", $0}'|sh This will nuke any i2c-headers, too, so we either have to re-emerge that or remove them from the list of to-be-copied files. Thus, emerge i2c again - emerge lm-sensors. lm-sensors orks, and compilation of programs works, too. Somehow I have the feeling that the way lm-sensors looks for things and the way kernel headers are treated are to blame for this foul-up. No, I have no idea how to fix this, but I guess, a close look at the lm-sensors Makefile might be revealing.
Alternatively, try this: cd /usr/include # move 2.4.19 headers out of the way mv asm asm.old mv linux linux.old # put our kernel headers in the way ln -sf /usr/src/linux/include/asm . ln -sf /usr/src/linux/include/linux . emerge i2c emerge lm-sensors And it should work.
When i comment out "patch -p 0 < ${FILESDIR}/${PV}-wrong-headers.patch || die" It picks the right include dir. I don't know gcc enough but maybe the -idirafter is no full replacement for -I. With the patch removed it's ok: # strings i2c-viapro.o | grep kernel_version kernel_version=2.4.20-gentoo-r5 With the "broke" patch it's bad # strings i2c-viapro.o | grep kernel_version kernel_version=2.4.19
I'm closing this as -r1 fixes this problem. [ The headers are copied to a temporary directory and lm-sensors uses that directory for I2C includes ]
