There is problem with x11-drivers/xf86-input-evdev-1.1.2-r2 compilation: make all-recursive make[1]: Entering directory `/var/tmp/portage/xf86-input-evdev-1.1.2-r2/work/xf86-input-evdev-1.1.2' Making all in src make[2]: Entering directory `/var/tmp/portage/xf86-input-evdev-1.1.2-r2/work/xf86-input-evdev-1.1.2/src' if /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -march=k8 -O2 -pipe -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../src -MT evdev_drv_la-evdev.lo -MD -MP -MF ".deps/evdev_drv_la-evdev.Tpo" -c -o evdev_drv_la-evdev.lo `test -f 'evdev.c' || echo './'`evdev.c; \ then mv -f ".deps/evdev_drv_la-evdev.Tpo" ".deps/evdev_drv_la-evdev.Plo"; else rm -f ".deps/evdev_drv_la-evdev.Tpo"; exit 1; fi if /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -march=k8 -O2 -pipe -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../src -MT evdev_drv_la-evdev_brain.lo -MD -MP -MF ".deps/evdev_drv_la-evdev_brain.Tpo" -c -o evdev_drv_la-evdev_brain.lo `test -f 'evdev_brain.c' || echo './'`evdev_brain.c; \ then mv -f ".deps/evdev_drv_la-evdev_brain.Tpo" ".deps/evdev_drv_la-evdev_brain.Plo"; else rm -f ".deps/evdev_drv_la-evdev_brain.Tpo"; exit 1; fi mkdir .libs x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -march=k8 -O2 -pipe -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../src -MT evdev_drv_la-evdev_brain.lo -MD -MP -MF .deps/evdev_drv_la-evdev_brain.Tpo -c evdev_brain.c -fPIC -DPIC -o .libs/evdev_drv_la-evdev_brain.o x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -march=k8 -O2 -pipe -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../src -MT evdev_drv_la-evdev.lo -MD -MP -MF .deps/evdev_drv_la-evdev.Tpo -c evdev.c -fPIC -DPIC -o .libs/evdev_drv_la-evdev.o evdev.c: In function 'EvdevSwitchMode': evdev.c:235: error: 'SendCoreEvents' undeclared (first use in this function) evdev.c:235: error: (Each undeclared identifier is reported only once evdev.c:235: error: for each function it appears in.) evdev.c:236: error: 'DontSendCoreEvents' undeclared (first use in this function) make[2]: *** [evdev_drv_la-evdev.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/xf86-input-evdev-1.1.2-r2/work/xf86-input-evdev-1.1.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/xf86-input-evdev-1.1.2-r2/work/xf86-input-evdev-1.1.2' make: *** [all] Error 2 !!! ERROR: x11-drivers/xf86-input-evdev-1.1.2-r2 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile ebuild.sh, line 1255: Called x-modular_src_compile x-modular.eclass, line 333: Called x-modular_src_make x-modular.eclass, line 328: Called die !!! emake failed !!! If you need support, post the topmost build error, and the call stack if relevant. Reproducible: Always
Created attachment 108817 [details] my emerge --info
You're building this driver against xorg-server-1.2, aren't you? You need the newer version (1.1.5).
actually, I tried to build it against the 1.1.1-r4 version. I downgraded all x11 relative staff to the stable version for amd64 I was not able to downgrade x11-drivers/xf86-input-evdev. I was forced to use xf86-input-evdev-1.1.5-r1.
It's possible you need to downgrade inputproto to 1.3.2 and rebuild libXi, xorg-server, etc. before evdev 1.1.2 will compile, but I'm not entirely sure. (That is, if you have newer inputproto/libXi installed.)
I'm hitting this same thing wrt the 2007.0 release. I can tell you what versions of what that we're using, if you need them. We pulled in the newer XCB-enabled stuff just yesterday since we had the newer libX11 due to the security bug, but our snapshot is from over a month ago otherwise. If I need to adjust any versions, let me know. I don't know what information you may need otherwise.
I get the same error on my x86 stable Gentoo. Stable 1.1.2-r2 fails but 1.1.5-r1 from testing works. I've tried to recompile all X-related stuff etc. but nothing has helped. I think the newer version needs to get stabilized.
Agreed. Using 1.1.5-r1 worked for me, also.
I am getting this same error while trying to build an x86 LiveCD on an amd64 platform. I am trying to keep everything very generic so I can continue to use the name spec files in the future so I am really stuck here. It appears to me that inputproto-1.4 has been unmasked for x86 and it is not including SendCoreEvents and DontSendCoreEvents in XI.h, so the compilation of xf86-input-evdev does not work. On amd64 inputproto-1.4 has not been unmasked yet, so I am still using 1.3.2 and everything works fine. So if I am seeing this correctly, stable x86 is broken right now and inputproto-1.4 needed to be masked again.
No, it's a bad idea to move something back to ~arch, and something that is discouraged by policy, especially when there is another solution. Mark 1.1.5-r1 stable.
Same problem here on a 2006.1 fresh configuration. Emerging the ~x86 version (1.1.5-r1) of xf86-input-evdev worked from me, too. CPU type: athlon64, legacy mode.
(In reply to comment #9) > No, it's a bad idea to move something back to ~arch, and something that is > discouraged by policy, especially when there is another solution. Mark > 1.1.5-r1 stable. > Fair enough, my point really is, don't leave stable broken like it has been for the last couple of days.
Just waiting on the maintainers to give us the go-ahead and I'll start marking. I'm just not positive if this is the course of action the maintainers want, or if they have a different/better solution. If I don't hear anything by the end of the day, I'll likely just start marking it stable on arches, since I've been testing this now on several arches for the release and it seems fine.
(In reply to comment #12) > Just waiting on the maintainers to give us the go-ahead and I'll start marking. > I'm just not positive if this is the course of action the maintainers want, or > if they have a different/better solution. If I don't hear anything by the end > of the day, I'll likely just start marking it stable on arches, since I've been > testing this now on several arches for the release and it seems fine. > We were going to stable 7.2 this weekend, so this works into our plans well. I'll change this bug so that evdev gets stabled sooner rather than later.
So can we add arches to CC now?
(In reply to comment #14) > So can we add arches to CC now? > Oh, yeah - sorry. I'll do that. ARM, MIPS and s390 will need to stable >=inputproto-1.4 as well.
Nevermind about s390, they don't have a keyword on this package.
The new stable evdev module seems broken for me (on x86). see http://forums.gentoo.org/viewtopic-t-555736.html I can't backdate to 1.1.2-r2 because of the compile error mentioned above. So X is (half) broken for me thanks to that update.
ppc64 stable
(In reply to comment #17) > The new stable evdev module seems broken for me (on x86). > > see http://forums.gentoo.org/viewtopic-t-555736.html > > I can't backdate to 1.1.2-r2 because of the compile error mentioned above. > So X is (half) broken for me thanks to that update. > Take a look at http://aarongyes.com/guides/mx1000 (from Googling 'mx1000 evdev').
marked ppc stable
(In reply to comment #19) > (In reply to comment #17) > > The new stable evdev module seems broken for me (on x86). > > > > see http://forums.gentoo.org/viewtopic-t-555736.html > > > > I can't backdate to 1.1.2-r2 because of the compile error mentioned above. > > So X is (half) broken for me thanks to that update. > > > > Take a look at http://aarongyes.com/guides/mx1000 (from Googling 'mx1000 > evdev'). > Thanks but their was nothing new to me. My setup is ok and always worked before
Stable on alpha
(In reply to comment #21) > Thanks but their was nothing new to me. My setup is ok and always worked before > You should file a new bug with the information you've given here.
05 May 2007; Daniel Gryniewicz <dang@gentoo.org> xf86-input-evdev-1.1.5-r1.ebuild: Marked stable on amd64 for bug #175465
Stable for HPPA.
mips stable.
