RivaTV-0.8.2 or 0.8.3 won't compile on 2.4.22-gentoo, due to missing symbols (inc_use/dec_use) which are now depreciated in new(er) i2c version. Reproducible: Always Steps to Reproduce: 1. emerge sources-test v2.4.22 2. ensure relevant i2c core kernel options are enabled 3. emerge any version of rivatv (or similar) or try compiling from sources direct from author Actual Results: ... rivatv-kcompat.h: In function `kcompat_i2c_client_get': rivatv-kcompat.h:116: warning: implicit declaration of function `i2c_inc_use_client' rivatv-kcompat.h: In function `kcompat_i2c_client_put': rivatv-kcompat.h:126: warning: implicit declaration of function `i2c_dec_use_client' i2c-riva.c: At top level: i2c-riva.c:242: unknown field `inc_use' specified in initializer i2c-riva.c:242: warning: initialization makes integer from pointer without a cast i2c-riva.c:243: unknown field `dec_use' specified in initializer i2c-riva.c:243: warning: initialization from incompatible pointer type i2c-riva.c:255: unknown field `inc_use' specified in initializer i2c-riva.c:255: warning: initialization makes integer from pointer without a cast i2c-riva.c:256: unknown field `dec_use' specified in initializer i2c-riva.c:256: warning: initialization from incompatible pointer type i2c-riva.c:268: unknown field `inc_use' specified in initializer i2c-riva.c:268: warning: initialization makes integer from pointer without a cast i2c-riva.c:269: unknown field `dec_use' specified in initializer i2c-riva.c:269: warning: initialization from incompatible pointer type make[2]: *** [i2c-riva.o] Error 1 make[2]: Leaving directory `/root/rivatvproblems/rivatv-0.8.3/src' make[1]: *** [_mod_/root/rivatvproblems/rivatv-0.8.3/src] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.22-gentoo' make: *** [all-kbuild] Error 2 Expected Results: Be nice if it could at least compile. :) Using test-source-2.4.22 compiled by genkernel. Initially spotted the issue with attempts to compile rivatv (any version). RivaTV complains about missing symbols, requires i2c_inc_use_client / i2c_dec_use_client. These _were_ exported by i2c-core.c in 2.4.20-gentoo kernel, however they're not exported by the version of i2c-core.c included in 2.4.22-gentoo. They _are_, however, included in the stock/standard 2.4.22 kernel; so I presume this relates to version issues between the backported version of i2c that this gentoo test kernel release is using. Readings of docs for i2c-2.8.0 onwards suggest that the use of inc_use & dec_use, which are used for module use counting, are depreciated, hence now removed. As such, either this version of the gentoo kernel will need to use an earlier or hacked version of i2c to work with some of the current releases of some software for which release-level ebuilds exist, which is probably silly, or much more sensibly, things like rivatv will need to be specifically patched to avoid the incompatibilities with the newer i2c -- which is probably much easier and more sensible, and for which patches already exist... see <URL:http://www.ensicaen.ismra.fr/~delvare/devel/i2c/other/rivatv-0.8.3-i2c- 2.8.0.patch> for a specific patch, and <URL:http://www.ensicaen.ismra.fr/~delvare/devel/i2c/> for many more. RivaTV is already full of kernel version specific patches, so I guess a few more won't hurt. :-} Ta-ra, Julie
not a kernel bug, this is a rivatv bug
Ok, the issue I see here is that the suggested patch activates code based on kernel version rather then i2c version. Or rather rivatv makes this decesion based on data not neccessarily authorative. I fear that doing this will break it for people running the current stable gentoo kernels. I will see if I can come up with a way to do better detection of the i2c version but I don't have a lot of time to devote to this and I no longer have this hardware in my posession.
Basically this *is* a kernel issue where someone put incompatible code to that version into the kernel train. Since it is an exception there is no clean way to fix this. I suggest you use a normal kernel instead...