Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 111363 - lirc-0.7.2 emerge fails, lirc_i2c.c: I2C_ALGO_BIT undeclared
Summary: lirc-0.7.2 emerge fails, lirc_i2c.c: I2C_ALGO_BIT undeclared
Status: RESOLVED DUPLICATE of bug 111820
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Heinrich Wendel (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-03 07:51 UTC by Daan van den Berg
Modified: 2005-11-17 22:58 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
2.6.14 kernel config (config-2.6.14-gentoo,38.46 KB, application/octet-stream)
2005-11-03 07:53 UTC, Daan van den Berg
Details
patch to compile lirc_i2c.c against 2.6.14 (lirc-0.7.2_kernel-2.6.14.patch,391 bytes, patch)
2005-11-04 03:07 UTC, Rene Wieben
Details | Diff
failed patch output (lirc-0.7.2_2.6.14.patch-7991.out,2.70 KB, text/plain)
2005-11-06 06:11 UTC, Shan Destromp
Details
pre-patched kcompat.h file for those having issues using the previous patch (kcompat.h,5.97 KB, text/plain)
2005-11-06 06:21 UTC, Shan Destromp
Details
patch that hopefully does apply (lirc-0.7.2_2.6.14.patch,391 bytes, patch)
2005-11-06 07:56 UTC, Rene Wieben
Details | Diff
ebuild with conditional haup patching (lirc-0.7.2-r1.ebuild,4.56 KB, text/plain)
2005-11-09 14:15 UTC, Shan Destromp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daan van den Berg 2005-11-03 07:51:16 UTC
emerging lirc-0.7.2 results in 'I2C_ALGO_BIT undeclared'-errors

Reproducible: Always
Steps to Reproduce:
1.emerge lirc
2.
3.




emerge lirc error:

Making all in lirc_i2c
make[3]: Entering directory
`/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c'
cd ../.. && \
  /bin/sh /var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/missing --run automake
--gnu  drivers/lirc_i2c/Makefile
cd ../.. && \
  CONFIG_HEADERS= CONFIG_LINKS= \
  CONFIG_FILES=drivers/lirc_i2c/Makefile /bin/sh ./config.status
creating drivers/lirc_i2c/Makefile
make[3]: Leaving directory
`/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c'
make[3]: Entering directory
`/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c'
mv Makefile Makefile.automake
cp ../Makefile.kernel Makefile
make -C /lib/modules/2.6.14-gentoo/build/
SUBDIRS=/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c modules \
        KBUILD_VERBOSE=1
make[4]: Entering directory `/usr/src/linux-2.6.14-gentoo'
mkdir -p /var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/.tmp_versions
make -f scripts/Makefile.build
obj=/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c
  gcc -m32
-Wp,-MD,/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/.lirc_i2c.o.d
 -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include -D__KERNEL__
-Iinclude  -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -ffreestanding -O2     -fomit-frame-pointer -pipe -msoft-float
-mpreferred-stack-boundary=2 -fno-unit-at-a-time -march=k8
-Iinclude/asm-i386/mach-default -Wdeclaration-after-statement 
-DIRCTL_DEV_MAJOR=61 -DEXPORT_SYMTAB -DHAVE_CONFIG_H -I. -I. -I../.. -I
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/../.. -I
/lib/modules/2.6.14-gentoo/build//include/  -DMODULE -DKBUILD_BASENAME=lirc_i2c
-DKBUILD_MODNAME=lirc_i2c -c -o
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.o
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c
In file included from include/linux/rcuref.h:36,
                 from include/linux/fs.h:12,
                 from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/../../drivers/lirc_dev/lirc_dev.h:24,
                 from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:58:
include/linux/interrupt.h:32:1: warning: "IRQ_NONE" redefined
In file included from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:57:
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/../../drivers/kcompat.h:167:1:
warning: this is the location of the previous definition
In file included from include/linux/rcuref.h:36,
                 from include/linux/fs.h:12,
                 from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/../../drivers/lirc_dev/lirc_dev.h:24,
                 from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:58:
include/linux/interrupt.h:33:1: warning: "IRQ_HANDLED" redefined
In file included from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:57:
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/../../drivers/kcompat.h:168:1:
warning: this is the location of the previous definition
In file included from include/linux/rcuref.h:36,
                 from include/linux/fs.h:12,
                 from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/../../drivers/lirc_dev/lirc_dev.h:24,
                 from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:58:
include/linux/interrupt.h:34:1: warning: "IRQ_RETVAL" redefined
In file included from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:57:
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/../../drivers/kcompat.h:169:1:
warning: this is the location of the previous definition
In file included from include/linux/rcuref.h:36,
                 from include/linux/fs.h:12,
                 from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/../../drivers/lirc_dev/lirc_dev.h:24,
                 from
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:58:
include/linux/interrupt.h:30: error: conflicting types for 'irqreturn_t'
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/../../drivers/kcompat.h:166:
error: previous declaration of 'irqreturn_t' was here
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c: In
function `ir_attach':
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:426:
error: `I2C_ALGO_BIT' undeclared (first use in this function)
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:426:
error: (Each undeclared identifier is reported only once
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:426:
error: for each function it appears in.)
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c: In
function `ir_probe':
/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.c:506:
error: `I2C_ALGO_BIT' undeclared (first use in this function)
make[5]: ***
[/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c/lirc_i2c.o] Error 1
make[4]: ***
[_module_/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c] Error 2
make[4]: Leaving directory `/usr/src/linux-2.6.14-gentoo'
make[3]: *** [lirc_i2c.o] Error 2
make[3]: Leaving directory
`/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers/lirc_i2c'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2/drivers'make[1]: ***
[all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/lirc-0.7.2/work/lirc-0.7.2'
make: *** [all] Error 2

My emerge info:

# emerge info
Portage 2.0.53_rc6 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r3,
2.6.14-gentoo i686)
=================================================================
System uname: 2.6.14-gentoo i686 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.12.0_pre9
ccache version 2.4 [enabled]
dev-lang/python:     2.3.5, 2.4.2
sys-apps/sandbox:    1.2.13
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -msse -msse2 -msse3 -m3dnow -mmmx -pipe
-fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c
/etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -msse -msse2 -msse3 -m3dnow -mmmx -pipe
-fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo
ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo
ftp://mirror.scarlet-internet.nl/pub/gentoo ftp://mirror.nutsmaas.nl/gentoo/
http://gentoo.mirror.intouch.nl/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage"
USE="x86 X a52 aac acpi alsa apache2 arts avi bash-completion berkdb
bitmap-fonts bluetooth bonobo bzip2 cdparanoia cdr clamav crypt cups curl dbus
divx4linux dv dvd dvdr dvdread eds emboss encode esd fam fame ffmpeg flac
foomaticdb fortran ftp gdbm gif ginac gnome gphoto2 gpm gstreamer gtk gtk2 hal
howl imagemagick imlib ipv6 java jpeg kde libg++ libwww lirc lm_sensors mad
mikmod motif mozilla mp3 mpeg msn mysql mythtv ncurses nls ogg oggvorbis opengl
oss pam pdflib perl php png ppds python qt quicktime readline samba sdl spell
ssl subtitles svg symlink tcltk tcpd tetex tiff truetype truetype-fonts
type1-fonts udev usb v4l vorbis win32codecs xine xml2 xmms xv xvid zlib
userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY

/etc/make.conf:

<snippet>
LIRC_OPTS="--with-x --with-driver=hauppauge"
</snippet>
Comment 1 Daan van den Berg 2005-11-03 07:51:49 UTC
created an attachment with kernel config
Comment 2 Daan van den Berg 2005-11-03 07:53:30 UTC
Created attachment 72018 [details]
2.6.14 kernel config
Comment 3 Rene Wieben 2005-11-04 03:07:24 UTC
Created attachment 72093 [details, diff]
patch to compile lirc_i2c.c against 2.6.14

This patch works for me
Comment 4 Daan van den Berg 2005-11-04 03:34:11 UTC
but not for me... or is it a kernel patch? well, it just gets really
frustrating, it even blocks an emerge -u world...

Comment 5 Rene Wieben 2005-11-04 04:51:39 UTC
eh, no it's not a kernel patch, it's a patch agains lirc-0.7.2.  
Of course you have to patch your lirc ebuild as well.   
...  
src_unpack() {  
        unpack ${A}  
        cd ${S} 
 
        epatch ${FILESDIR}/lirc-0.7.2_2.6.14.patch 
  
        #epatch ${FILESDIR}/lirc-0.7.0-xbox.patch.bz2  
...  
Comment 6 Shan Destromp 2005-11-06 06:11:20 UTC
I'm having the same issue as Daan seems to be in getting the patch to apply.

ami# cat /usr/local/portage-homebrew/app-misc/lirc/lirc-0.7.2-r1.ebuild
<snip>
src_unpack() {
        unpack ${A}
        cd ${S}
        #epatch ${FILESDIR}/lirc-0.7.0-xbox.patch.bz2
        epatch ${FILESDIR}/lirc-0.7.2_2.6.14.patch

</snip>

ami# cat /usr/local/portage-homebrew/app-misc/lirc/files/lirc-0.7.2_2.6.14.patch
--- drivers/kcompat.h   2005-11-04 11:17:11.000000000 +0100
+++ drivers/kcompat.h   2005-11-04 11:16:06.000000000 +0100
@@ -162,6 +162,7 @@
 #define MODULE_DEVICE_TABLE(x,y)
 #endif

+#include <linux/interrupt.h>
 #ifndef IRQ_RETVAL
 typedef void irqreturn_t;
 #define IRQ_NONE
@@ -226,4 +226,9 @@

 #endif

+#ifndef I2C_ALGO_BIT
+#   define I2C_ALGO_BIT 0
+#endif
+
 #endif /* _KCOMPAT_H */

ami temp # emerge --info
Portage 2.0.53_rc7 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r3,
2.6.14-gentoo x86_64)
=================================================================
System uname: 2.6.14-gentoo x86_64 AMD Athlon(tm) 64 Processor 3500+
Gentoo Base System version 1.12.0_pre9
dev-lang/python:     2.4.2
sys-apps/sandbox:    1.2.13
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict unsermake"
GENTOO_MIRRORS="http://prometheus.cs.wmich.edu/gentoo
http://mirror.mcs.anl.gov/pub/gentoo/ http://gentoo.mirrors.pair.com/
http://mirror.datapipe.net/gentoo http://mirrors.acm.cs.rpi.edu/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage-homebrew"
SYNC="rsync://10.0.0.1/gentoo-portage"
USE="amd64 X alsa arts artswrappersuid avi bitmap-fonts cairo cdr clock-screen
crypt divx4linux dvd dvdr dvdread emboss encode fam firefox foomaticdb fortran
gif gtk gtk2 imlib insecure-savers jpeg kde kdeenablefinal key-screen lirc lzw
lzw-tiff mad mouse moznocompose moznoirc moznomail mozvg mp3 mpeg ncurses nls
nptl nptlonly nvidia opengl pam pdflib perl png python qt quicktime readline sdl
search-screen spell sqlite ssl symlink tcpd thebes tiff transcode truetype-fonts
type1-fonts udev usb userlocales xine xml2 xpm xv xvid zlib userland_GNU
kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS


Follows will be my patch.out file
Comment 7 Shan Destromp 2005-11-06 06:11:25 UTC
Created attachment 72295 [details]
failed patch output
Comment 8 Shan Destromp 2005-11-06 06:21:06 UTC
Created attachment 72297 [details]
pre-patched kcompat.h file for those having issues using the previous patch

I took to manually patching the drivers/kcompat.h file (edit it, copy to a safe
location, start a non-patch-applying build, wait till its finished unpacking;
hit CTRL-Z; copy the patched version over to the build dir; then fg to resume
build) and it built cleanly.

Not sure how to make a patch file; so I've just attached my kcompat.h file
Comment 9 Rene Wieben 2005-11-06 07:56:45 UTC
Created attachment 72312 [details, diff]
patch that hopefully does apply

yeah, you're right, the original patch doesn't apply. Try this one.
Comment 10 Shan Destromp 2005-11-06 16:03:15 UTC
(In reply to comment #9)
> Created an attachment (id=72312) [edit]
> patch that hopefully does apply
> 
> yeah, you're right, the original patch doesn't apply. Try this one.

Works for me on amd64; same emerge --info as before.
Comment 11 Daan van den Berg 2005-11-07 00:25:51 UTC
Well, still no use... Same error message with the new patch. I'm a n00b when it
comes to creating patches, so please don't expect me to do such things myself, I
really can't (and besides, I don't have time for it). Thanks for all the patches
and support, but I'm thinking about giving up (unless someone can convince me
not to ;) )

Comment 12 Daan van den Berg 2005-11-07 00:43:43 UTC
Well, at least I found something. Scrolled through the lirc_i2c.c file (didn't
understand much, to be honest) and found the following lines:

static int ir_attach(struct i2c_adapter *adap, int addr,
		     unsigned short flags, int kind)
{
        struct IR *ir;
	
        client_template.adapter = adap;
        client_template.addr = addr;
	
        if (NULL == (ir = kmalloc(sizeof(struct IR),GFP_KERNEL)))
                return -ENOMEM;
        memcpy(&ir->l,&lirc_template,sizeof(struct lirc_plugin));
        memcpy(&ir->c,&client_template,sizeof(struct i2c_client));
	
	ir->c.adapter = adap;
	ir->c.addr    = addr;
	i2c_set_clientdata(&ir->c, ir);
	ir->l.data    = ir;
	ir->l.minor   = minor;
	ir->l.sample_rate = 10;
	ir->nextkey   = -1;

	switch(addr)
	{
	case 0x64:
		strcpy(ir->c.name,"Pixelview IR");
		ir->l.code_length = 8;
		ir->l.add_to_buf=add_to_buf_pixelview;
		break;
	case 0x4b:
		strcpy(ir->c.name,"PV951 IR");
		ir->l.code_length = 32;
		ir->l.add_to_buf=add_to_buf_pv951;
		break;
	case 0x71:
		/* The PVR150 IR receiver uses the same protocol as other 
		   Hauppauge cards, but the data flow is different, so we need
		   to deal with it by its own.
		 */
		strcpy(ir->c.name,"Hauppauge IR (PVR150)");
		ir->l.code_length = 13;
		ir->l.add_to_buf=add_to_buf_haup_pvr150;
		break;
	case 0x6b:
		strcpy(ir->c.name,"Adaptec IR");
		ir->l.code_length = 32;
		ir->l.add_to_buf=add_to_buf_adap;
		break;
	case 0x18:
	case 0x1a:
		if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848)) {
			strcpy(ir->c.name,"Hauppauge IR");
			ir->l.code_length = 13;
			ir->l.add_to_buf=add_to_buf_haup;
		}
		else {
			strcpy(ir->c.name,"Leadtek IR");
			ir->l.code_length = 8;
			ir->l.add_to_buf=add_to_buf_pvr2000;
		}
		break;
	case 0x30:
		strcpy(ir->c.name,"KNC ONE IR");
		ir->l.code_length = 8;
		ir->l.add_to_buf=add_to_buf_knc1;
		break;
	case 0x21:
	case 0x23:
		strcpy(ir->c.name,"TV-Box IR");
		ir->l.code_length = 8;
		ir->l.add_to_buf=add_to_buf_pcf8574;
		ir->bits = flags & 0xff;
		ir->flag = (flags >> 8) & 0xff;
		break;
		
	default:
		/* shouldn't happen */
		printk("lirc_i2c: Huh? unknown i2c address (0x%02x)?\n",addr);
		kfree(ir);
		return -1;
	}
	printk("lirc_i2c: chip found @ 0x%02x (%s)\n",addr,ir->c.name);
	
	/* register device */
	i2c_attach_client(&ir->c);
	ir->l.minor = lirc_register_plugin(&ir->l);
	i2c_use_client(&ir->c);
	
	return 0;
}

As I have a Hauppauge PVR150, could it be that lirc_i2c.c tries to use the wrong
device? There's seperate lines for the PVR150, but how to reach those?
Comment 13 Rene Wieben 2005-11-07 02:19:12 UTC
No, the problem is not in lirc_i2c.c . I've got a pvr500 (which is 2 pvr150's 
in one, with an internal pci-pci bridge) and had exactly the same error 
messages as you have. I resolved them by applying my patch. So I guess you 
either have to to figure out how to apply a patch, or wait until the 
lirc-ebuild gets updated.  
Comment 14 Daan van den Berg 2005-11-07 02:41:55 UTC
I don't know what exactly happened, or what I did, but suddenly it worked. I
think it had to do by first commenting the LIRC_OPTS line in /etc/make.conf,
emerging lirc and after that uncommenting the LIRC_OPTS line again and
re-emerging lirc. Don't know if it could be like this but for me it worked all
of a sudden... Thanks anyway and I will mark this one as solved.
Comment 15 Daan van den Berg 2005-11-07 02:43:24 UTC
again, it is SOLVED
Comment 16 Shan Destromp 2005-11-07 16:17:25 UTC
(In reply to comment #15)
> again, it is SOLVED

Uh, solved implies that the problem won't be experianced by other users anymore;
since there hasn't been a rev-bump to the portage version to either incorporate
Rene's patch, or similar; others will still encounter the problem.  Granted
they'll find a solution but thats besides the point.  Whatever.

At any rate, I did a local test to see if Daan's solution did work, and it seems
to.  Trying to merge (an unpatched) lirc with  my LIRC_OPTS line in make.conf
fails as previously noted but commenting it out the build executes fine.
Comment 17 Daan van den Berg 2005-11-07 23:04:38 UTC
whoops...

didn't know about that. thanks for the info!
Comment 18 Daan van den Berg 2005-11-08 00:01:53 UTC
Well, I think the workaround doesn't work after all... It was the
--with-driver=serial option that worked somehow, but the --with-driver=hauppauge
option DOES NOT. 

Guess that means to reopen the bug?
Comment 19 Rene Wieben 2005-11-08 04:26:49 UTC
yes, I think you should reopen it. It does compile without 
--with-driver=hauppauge, but then it doesn't compile the i2c driver, so your 
hauppauge remote doesn't work. 
Comment 20 Daan van den Berg 2005-11-08 05:49:25 UTC
Seems like this is a specific 2.6.14 kernel problem. I downgraded my kernel to
2.6.13-r5, and lirc compiled without problems, even with the
LIRC_OPTS="--with-driver=hauppauge" option. Seems like downgrading is the only
option here...

Comment 21 Shan Destromp 2005-11-08 14:32:51 UTC
(In reply to comment #20)
> Seems like this is a specific 2.6.14 kernel problem. I downgraded my kernel to
> 2.6.13-r5, and lirc compiled without problems, even with the
> LIRC_OPTS="--with-driver=hauppauge" option. Seems like downgrading is the only
> option here...
> 
> 

The patch that Rene posted in comment *does* work, atleast for me.  It both
allows lirc to compile cleanly, and I get a positive response with my remote,
testing with `irw`.

You (Daan) mentioned the new patch gave you an error, what was it?  Alternately,
you can use the (pre patched) kcompat.h file I provided earlier.
Comment 22 Daan van den Berg 2005-11-09 02:42:33 UTC
> The patch that Rene posted in comment *does* work, atleast for me.  It both
> allows lirc to compile cleanly, and I get a positive response with my remote,
> testing with `irw`.
> You (Daan) mentioned the new patch gave you an error, what was it?  
Alternately,
> you can use the (pre patched) kcompat.h file I provided earlier.

The error the new patch gave me was exactly the same as before. I really don't 
know how to apply the pre patched kcompat.h file, despite your explanation in 
your post (kinda n00b...) I have downgraded my kernel now to 2.6.13-r5, and now 
lirc compiles without any problem, I even get pos response with my remote 
with 'irw'. The only problem left is that MythTV doesn't work as expected 
(mythfilldatabase etc), but that's beyond the scope of this thread.
Comment 23 Shan Destromp 2005-11-09 14:15:23 UTC
Created attachment 72519 [details]
ebuild with conditional haup patching

(In reply to comment #22)
> > The patch that Rene posted in comment *does* work, atleast for me.	It both

> > allows lirc to compile cleanly, and I get a positive response with my
remote,
> > testing with `irw`.
> > You (Daan) mentioned the new patch gave you an error, what was it?	
> Alternately,
> > you can use the (pre patched) kcompat.h file I provided earlier.
> 
> The error the new patch gave me was exactly the same as before. I really
don't 
> know how to apply the pre patched kcompat.h file, despite your explanation in

> your post (kinda n00b...) I have downgraded my kernel now to 2.6.13-r5, and
now 
> lirc compiles without any problem, I even get pos response with my remote 
> with 'irw'. The only problem left is that MythTV doesn't work as expected 
> (mythfilldatabase etc), but that's beyond the scope of this thread.


Such is the problem when you've got too many bugs and not enough developers,
the  `true solution` to this is as simple as rev-bumping the ebuild to apply
Rene's patch; which is why I've gone and made an updated ebuild file.

The actions are quite hackish, I couldn't figure out how to read the in-ebuild
copy of LIRC_OPTS so I create a var called MY_LIRC_OPTS via some grepping and
sed of /etc/make.conf (which means this wont work if you set LIRC_OPTS via
command line). Unfortunately I don't have the time to do this right; and even
this much took me far longer than I'd planned.

Daan, you'll want to take a look at Gentoo-wiki's guide to using an overlay,
which'll describe how to properly use this ebuild:
http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds
Comment 24 Doug Goldstein (RETIRED) gentoo-dev 2005-11-17 22:58:36 UTC

*** This bug has been marked as a duplicate of 111820 ***