Summary: | xorg-server / kernel headers 2.6.26 - vm86.c:225: error: 'IF_MASK' undeclared (first use in this function) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | lexx <lexxkind> |
Component: | [OLD] Unspecified | Assignee: | Gentoo X packagers <x11> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | 7words.sg, andriy155, jaak, lack, limanski, maekke, Martin.vGagern, mike, steev, stephan.menzel, tais.hansen, web.alexander |
Priority: | High | Keywords: | Inclusion |
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Have vm86.h fall back to X86_EFLAGS_* |
Description
lexx
2008-08-26 15:06:40 UTC
Have you tried with Default CFLAGS? Yes, those are horrible CFLAGS, but that's not the problem. Right, those flags are horrible, but this is actually caused by kernel headers 2.6.26. All of those flags have been renamed there. I can't recall the numbers, but I've already seen similar bugs wrt. different packages. http://bugs.gentoo.org/show_bug.cgi?id=235310#c6 has a suggested fix. *** Bug 235575 has been marked as a duplicate of this bug. *** Created attachment 165037 [details, diff] Have vm86.h fall back to X86_EFLAGS_* This is an adaptation of the fix mentioned in comment #4 to xorg-server. Thanks for the referene! The fix uses X86_EFLAGS_IF and X86_EFLAGS_IOPL if IF_MASK and IOPL_MASK haven't been defined already. These EFLAGS come from /usr/include/asm/processor-flags.h which gets included from asm/vm86.h which gets included from sys/vm86.h which is already included in the vm86.h from xorg-server. An alternative I mentioned in bug 236910 (which I consider a dup of this here) would be the constants X86_IF_MASK and X86_IOPL_MASK from the hw/xfree86/int10/xf86int10.h header file present in the xorg-server source tree. Up to now, Upstream doesn't seem to have addressed this issue: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=tree;f=hw/kdrive/vesa I couldn't find a bug report either. Is this issue due to some strange and nonstandard configuration of the installed linux headers, or would other distributions suffer similar issues and the problem should be taken upstream? *** Bug 236910 has been marked as a duplicate of this bug. *** Still an issue with xorg-server-1.5.1. The attached patch still fixes it. Please add it to the portage tree. For reference, this seems to be the upstream kernel commit which removed the definitions from the vm86.h header file. http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commitdiff;h=a5c15d419d4b68535222b51f9054dd08d5e67470 Message: "x86: replace most VM86 flags with flags from processor-flags.h" From this I take it that a) the issue is probably not Gentoo-specific b) the attached fix matches the fix in the kernel sources quite well I had a look at the package linux-libc-dev of Debian sid and Ubuntu intrepid. Debian still contains those flags, while Ubuntu has lost them. Therefore building kdrive-vesa on Ubuntu should expose this issue as well. The Debian based packages are configured with --disable-kdrive-vesa by default, so the issue doesn't show up for the official packages. http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commitdiff;h=50ddaffe30920254835c7bfcc152a3f9860d1c2a On the whole I think this is a bug to be addressed upstream as well. I'll file a bug report there, and post its URL here. But don't wait for upstream to include this fix in Gentoo. (In reply to comment #9) > On the whole I think this is a bug to be addressed upstream as well. I'll file > a bug report there, and post its URL here. Reported as http://bugs.freedesktop.org/show_bug.cgi?id=17858 Just like to throw in that the patch did indeed work here as well, on my x86 boxes, Thanks for the patch Martin, its nice to be able to use Xephyr again! *** Bug 240328 has been marked as a duplicate of this bug. *** Still an issue with x11-base/xorg-server-1.5.2, upstream bug still not fixed. xorg-server is quite a lengthy build, and having to compile it twice due to this issue can become rather annoying. Please add this patch to portage. I confirm this issue still exists in 1.5.2 and that the patch works fine. Could we please fix this annoying issue? *** Bug 242480 has been marked as a duplicate of this bug. *** (In reply to comment #14) > I confirm this issue still exists in 1.5.2 and that the patch works fine. Could > we please fix this annoying issue? Seconded. Would any of the x11 team mind if one of us other devs did it? This one is getting more annoying now because of this one: http://bugs.gentoo.org/show_bug.cgi?id=199282 I had to mask xorg-server => 1.5.0 because of this bug and now I ended up not being able to build xorg because 1.4 and lower don't seem to have the 'nptl' USE flag which in turn is interfering with mesa. Weird. Can anyone tell me how I apply this patch you provided during build? Thanks! Stephan (In reply to comment #17) > I had to mask xorg-server => 1.5.0 because of this bug You really need kdrive? Otherwise "USE=-kdrive emerge xorg-server" is for you. > Can anyone tell me how I apply this patch you provided during build? As the Wiki is currently down, I give you a link to archived versions instead: http://web.archive.org/web/*/http://gentoo-wiki.com/HOWTO_Create_an_Updated_Ebuild Especially note the section "Adding a patch". For further support ask on IRC, as this bug report here is not the place for learning about portage. That worked, thank you. I did indeed have the kdrive use flag but didn't actually know why. Disabling it solved this. However, I didn't see that hint in the bug here until you told me so maybe it would be a good idea to issue such a comment after the ebuild fails. Just in case. Thanks a lot! Stephan (In reply to comment #19) > maybe it would be a good idea to issue such a comment after the ebuild fails. If someone were to actually modify the ebuild in the portage tree, I'd rather prefer him to include the fix than a comment about the error. (In reply to comment #16) > Seconded. Would any of the x11 team mind if one of us other devs did it? No complaints in 4+ days, please go ahead! Done. And I've sent the patch upstream through the mailing list where I think it has a better chance of being seen/acked than through bugzilla. Thanks Quick follow up, Martin's patch was accepted into 1.5.3 and upstream devs agreed to kill Xvesa off completely from master. Thanks *** Bug 256006 has been marked as a duplicate of this bug. *** To be strict - in Gentoo this bug IS STILL PRESENT in the stable x11-base/xorg-server-1.3.0.0-r6, just as mentioned in bug 256006. This bug was marked RESOLVED and even CLOSED last year, but I still got a compilation error this very day... Or is this a WONTFIX, DONTCARE? I'm a bit frustrated by this. Until properly handled, the issue at hand might still anger even more users. Well, I believe REOPEN would then be appropriate. Why didn't you? Cheers, Stephan (In reply to comment #25) > Well, I believe REOPEN would then be appropriate. Why didn't you? > > Cheers, > > Stephan > I would, if I could. But as this Bugzilla allows me only to choose "Leave as CLOSED FIXED" for this bug, I'm not left with much options. Kdrive on 1.3 is broken. Either don't use it (USE=-kdrive) or upgrade to 1.5.3 which will go stable Very Soon (tm) Thanks (In reply to comment #27) > Kdrive on 1.3 is broken. Either don't use it (USE=-kdrive) or upgrade to 1.5.3 > which will go stable Very Soon (tm) > > Thanks > Then shouldn't that USE-flag be masked or something to prevent other users from running into the same problem again? Is it so difficult to fix version 1.3? As I see the fix is trivial. I subscribed bug 256006 for, but it was closed as duplicate. If USE kdrive is allowed for xorg-server-1.3 it shall works fine, regardless that the new xorg is comming soon. (In reply to comment #27) > which will go stable Very Soon (tm) Hi Remi, Could you clarify, if you have any estimations for stabilization date? BR. (In reply to comment #30) > Could you clarify, if you have any estimations for stabilization date? Basically, all that's left to do is to write an upgrade guide. Unfortunately, Real Life is keeping me away from doing this properly. I'm still aiming for stabilization before the end of March. If anything, you should head over to the stabilization bug and follow the upgrade procedure. You'll get a head start on the stabilization process. Thanks |