Created attachment 19331 [details] [review] Have vm86.h fall back to X86_EFLAGS_* Since http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commitdiff;h=a5c15d419d4b68535222b51f9054dd08d5e67470 the linux kernel headers no longer define IF_MASK and IOPL_MASK. The kernel code uses X86_EFLAGS_IF and X86_EFLAGS_IOPL instead. The xserver file hw/kdrive/vesa/vm86.c uses IF_MASK and IOPL_MASK and therefore won't compile any more on systems with such headers installed. The xorg sources should be modified to use the newer flags, at least in cases where the older ones are not defined. An alternative might be the constants X86_IF_MASK and X86_IOPL_MASK from the hw/xfree86/int10/xf86int10.h header file. They contain the same values. However, getting this file included would probably require more hacking, and there is little to be gained from it. I originally found this issue in the Gentoo linux bug tracker: http://bugs.gentoo.org/show_bug.cgi?id=235789 I'll also attach the patch I used to fix the issue on Gentoo.
On Wed, Oct 01, 2008 at 10:29:23AM -0700, bugzilla-daemon@freedesktop.org wrote: > The xserver file hw/kdrive/vesa/vm86.c uses IF_MASK and IOPL_MASK and therefore > won't compile any more on systems with such headers installed. The xorg sources > should be modified to use the newer flags, at least in cases where the older > ones are not defined. > > An alternative might be the constants X86_IF_MASK and X86_IOPL_MASK from the > hw/xfree86/int10/xf86int10.h header file. They contain the same values. > However, getting this file included would probably require more hacking, and > there is little to be gained from it. > > I originally found this issue in the Gentoo linux bug tracker: > http://bugs.gentoo.org/show_bug.cgi?id=235789 > I'll also attach the patch I used to fix the issue on Gentoo. Um, why are you using Xvesa? Xorg shouldn't be compellingly larger, and most of the bits that make a difference (hello pcidata) should be optional.
(In reply to comment #1) > Um, why are you using Xvesa? I'm not actually using it, I'm just compiling it. I want Xephyr, so I requested kdrive support from the Gentoo package (USE=kdrive in Gentoo talk), which resulted in the configure option --enable-kdrive without further restrictions, especially without --disable-kdrive-vesa. So yes, the Gentoo ebuild could be changed to always --disable-kdrive-vesa, or to add a separate configuration flag for this. On the other hand, whether I actually use it should be secondary. The Xvesa code is there, the build system supports it, even enables kdrive-vesa by default if kdrive is enabled. While the build currently fails, there is an easy fix, and I see no reason not to fix it, and let people decide whether or not to use it. If you indeed argue that Xvesa is unlikely to ever be useful, you might make --disable-kdrive-vesa the default, even for --enable-kdrive builds. That way, people who actually want Xvesa would be forced to use one more configure switch, resulting in faster builds and smaller installs for some users.
Fixed in 1.5 branch, and in an entirely different way in master. Thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.