After emerge syncing and emerge -U world, DirectFB-0.9.19-r1 is in the upgrade list (upgrading from DirectFB-0.9.18), however it fails on compile: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src -I /usr/include/libmpeg3 -D_REENTRANT -Wall -O3 -ffast-math -pipe -march=pentium4 -O3 -pipe -fomit-frame-pointer -DFUSION_FAKE -Werror-implicit-function-declaration -c matrox_maven.c -fPIC -DPIC -o matrox_maven.lo matrox_maven.c:32:27: linux/i2c-dev.h: No such file or directory matrox_maven.c: In function `maven_write_byte': matrox_maven.c:63: implicit declaration of function `i2c_smbus_write_byte_data' matrox_maven.c: In function `maven_write_word': matrox_maven.c:80: implicit declaration of function `i2c_smbus_write_word_data' matrox_maven.c: In function `maven_open': matrox_maven.c:311: `I2C_SLAVE' undeclared (first use in this function) matrox_maven.c:311: (Each undeclared identifier is reported only once matrox_maven.c:311: for each function it appears in.) matrox_maven.c: In function `maven_init': matrox_maven.c:450: `I2C_SLAVE' undeclared (first use in this function) make[3]: *** [matrox_maven.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/DirectFB-0.9.19-r1/work/DirectFB-0.9.19/gfxdrivers/matrox' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/DirectFB-0.9.19-r1/work/DirectFB-0.9.19/gfxdrivers' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/DirectFB-0.9.19-r1/work/DirectFB-0.9.19' make: *** [all-recursive-am] Error 2 !!! ERROR: dev-libs/DirectFB-0.9.19-r1 failed. !!! Function src_compile, Line 54, Exitcode 2 !!! (no error message) Reproducible: Always Steps to Reproduce: 1. emerge sync 2. emerge -U world (or emerge -U DirectFB) 3. Actual Results: DirectFB-0.9.19-r1 fails on compile. Expected Results: DirectFB-0.9.19-r1 is merged into system successfully. Portage 2.0.49-r3 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.4.20-gentoo-r7) ================================================================= System uname: 2.4.20-gentoo-r7 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://194.83.57.2/sites/www.ibiblio.org/gentoo/ http://194.83.57.11/sites/www.ibiblio.org/gentoo/ http://ftp.easynet.nl/mirror/gentoo/ http://194.83.57.7/sites/www.ibiblio.org/gentoo/ ftp://ftp.easynet.nl/mirror/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="oss foomaticdb libg++ pdflib quicktime zlib gdbm berkdb slang readline tcpd pam esd gnome qt motif aalib acpi alsa apm avi cdr crypt dga directfb dvd encode fbcon gd ggi gif gtk gtkhtml imap imlib java jpeg libwww mad mikmod mmx mozilla mpeg ncurses opengl oggvorbis pdf perl png python sdl spell sse ssl svga tiff truetype usb wmf X xml xml2 xmms xv x86 -gpm -cups -kde -arts -nls"
hmm i wonder if i2c is required for directfb to work
looks like the matrox driver explicitly requires i2c support ... i guess the solution is to add a variable so that users can build support for the video cards they have and we'll disable matrox by default since it comes with this baggage
hmm, have you done anything fancy with /usr/include/linux ? what does `qpkg -I -v linux-header` show ? what about `qpkg -v -f /usr/include/linux` ?
Spanky, AFAIK I haven't done anything with those. xerxes root # qpkg -I -v linux-header sys-kernel/linux-headers-2.4.19-r1 * xerxes root # qpkg -v -f /usr/include/linux/ xerxes root #
Sorry, shouldn't have had that trailing slash: xerxes root # qpkg -v -f /usr/include/linux sys-apps/baselayout-1.8.6.10-r1 * sys-kernel/linux-headers-2.4.19-r1 * xerxes root #
what does `ls /usr/include/linux/*i2c*` ?
omicron@xerxes omicron $ ls /usr/include/linux/*i2c* /usr/include/linux/i2c-algo-ite.h /usr/include/linux/i2c-old.h
what if you re-emerge linux-headers ? if that doesnt work, what does `qpkg -l linux-headers | grep i2c` show ?
I have the same problem and I'm pretty sure that I didn't play with the kernel-headers, but: The file i2c-dev.h the ebuild isn't comfortable with, is from i2c-2.7.0. (compared merge and file date)
Re-emerging linux-headers seems to have fixed the problem. As far as I'm aware, I didn't do anything to linux-headers myself, other than upgrading the last time it's version bumped.
carlo: does re-emerging linux-headers fix your problem too ? if so, did you guys utilize the i2c ebuild at all ? and ignore my previous comments about messing around with kernel headers, that was an assumption of mine that proved wrong ;)
I remember using the i2c ebuild at one point. I *think* I emerged i2c in an attempt to see if I had sensors on my motherboard, and was following some guides in the forums about emerge i2c and compiling support in my kernel. Since then, I've removed support from the kernel and unmerged i2c. Not much point in having them here if I don't actually have sensors on the mobo. ;)
ok kernel guys heres the bug: emerge linux-headers ls /usr/include/linux/*i2c* emerge i2c emerge -C i2c ls /usr/include/linux/*i2c* you should see a bunch of i2c headers have gone mia :)
SpanKY: Yes, it does. > if so, did you guys utilize the i2c ebuild at all ? If the i2c support in current gentoo-sources were not broken (due to ptrace bugfix iirc), then I would use it...
Does this happen with i2c-2.8.0 [ebuild...] Is this bug still relevant?
plasmaroo: i dont know, i dont use linux-headers or i2c ... i gave you a way to test to see if the bug exists or not ;) simply `ebuild i2c.ebuild clean unpack compile install ; ls ${D}/usr/include/ -R` and see if it installed the i2c headers
SpanKY: The 2.7.0 ebuild had some bugs and such [AFAIK] and the 2.8.0 ebuild which I wrote shouldn't get this problem [and mine actually compiles as well]... And anyway, the problem is at Person X's end: our job is to figure out why it happens THERE not whether it happens on our boxen :-) Finally, i2c 2.7.0 doesn't merge for me... I'm sticking a merge output of 2.8.0 below, and it seems that 2.7.0 does things a little differently? // >>> Completed installing into /var/tmp/portage/i2c-2.8.0/image/ >>> Merging sys-apps/i2c-2.8.0 to / --- /usr/ --- /usr/share/ --- /usr/share/doc/ --- /usr/share/doc/i2c-2.8.0/ >>> /usr/share/doc/i2c-2.8.0/README.gz >>> /usr/share/doc/i2c-2.8.0/INSTALL.gz >>> /usr/share/doc/i2c-2.8.0/CHANGES.gz --- /usr/include/ --- /usr/include/linux/ >>> /usr/include/linux/i2c-proc.h >>> /usr/include/linux/i2c-algo-biths.h >>> /usr/include/linux/i2c-algo-pcf.h >>> /usr/include/linux/i2c-id.h >>> /usr/include/linux/i2c-algo-bit.h >>> /usr/include/linux/i2c-dev.h >>> /usr/include/linux/i2c.h --- /lib/ --- /lib/modules/ >>> /lib/modules/2.4.20-gentoo-r7/ >>> /lib/modules/2.4.20-gentoo-r7/kernel/ >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/ >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/ >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/i2c-algo-bit.o >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/i2c-pport.o >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/i2c-proc.o >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/i2c-velleman.o >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/i2c-elv.o >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/i2c-algo-pcf.o >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/i2c-core.o >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/i2c-algo-biths.o >>> /lib/modules/2.4.20-gentoo-r7/kernel/drivers/i2c/i2c-dev.o /// Can somebody please stick what merge output you get on 2.7.0?
Sure. >>> Merging sys-apps/i2c-2.7.0 to / --- /lib/ --- /lib/modules/ --- /lib/modules/2.4.20-gentoo-r6/ --- /lib/modules/2.4.20-gentoo-r6/misc/ >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-core.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-pport.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-algo-bit.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-algo-pcf.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-proc.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-philips-par.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-elektor.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-dev.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-elv.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-pcf-epp.o >>> /lib/modules/2.4.20-gentoo-r6/misc/i2c-velleman.o --- /usr/ --- /usr/share/ --- /usr/share/doc/ --- /usr/share/doc/i2c-2.7.0/ >>> /usr/share/doc/i2c-2.7.0/README.gz >>> /usr/share/doc/i2c-2.7.0/INSTALL.gz >>> /usr/share/doc/i2c-2.7.0/CHANGES.gz --- /usr/include/ --- /usr/include/linux/ >>> /usr/include/linux/i2c.h >>> /usr/include/linux/i2c-algo-bit.h >>> /usr/include/linux/i2c-algo-pcf.h >>> /usr/include/linux/i2c-proc.h >>> /usr/include/linux/i2c-elektor.h >>> /usr/include/linux/i2c-dev.h >>> /usr/include/linux/i2c-pcf8584.h >>> /usr/include/linux/i2c-id.h
Comment #10 says this is fixed, so I'm marking it as such as a user-side problem. This might be something to do with kernel-headers not being slotted properly to 0 at the time: they're all now slotted to zero now, FYI.
