| Summary: | xorg-x11 fails to work on G5, however work with patch | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Yuta SATOH (RETIRED) <nigoro> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | brad, ppc64 |
| Priority: | Lowest | ||
| Version: | unspecified | ||
| Hardware: | PPC64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
patch for xorg-x11 ebuild
patch for xorg-x11 ebuild patch for xorg-x11 ebuild patch for xorg-x11 ebuild |
||
|
Description
Yuta SATOH (RETIRED)
2004-07-06 09:06:47 UTC
The contents of an error when xorg-x11 fails to work. [snip] Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.7 Build Operating System: Linux 2.6.6-r0 ppc64 [ELF] *snip* (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting [snip] Created attachment 34872 [details, diff]
patch for xorg-x11 ebuild
Created attachment 35064 [details, diff]
patch for xorg-x11 ebuild
This new patch solves the problem which cannot use DRI module and GLX module.
Additional information
The display drivers which can be used by applying this patch are ati and fbdev.
Created attachment 35315 [details, diff]
patch for xorg-x11 ebuild
I think that this patch can use a display driver nv newly.
However, since I do not have the board of nVidia, I cannot do a test.
Could anyone test this patch?
*** Bug 54852 has been marked as a duplicate of this bug. *** Created attachment 35493 [details, diff]
patch for xorg-x11 ebuild
I'm very sorry.
The line feed code of the patch in front of one was CR LF.
Grabbing. I want patch changes to go through me. Note to Spyderous Just grab the last xorg-x11.ebuild patch and use that. If you need an explation as to why it's doing what it's doing contact me (tgall@gentoo.org) or get ahold of me on irc. in a nutshell the xorg folks still use their own elf loader for loading .o's when they really shouldn't be using .o's anymore but rather .so's ... anyway this would reqiure some significant work in their own elf loader for ppc64. I might put the time and effort into that eventually (or if someone else wants to do that) but not right now. Really the "right" fix is for xorg not to use .o's entirely and deprecate their own elf loader. The ppc64 patch for xorg support is already in portage. Feel free to swizzle that into your patch tarball or whatever voodoo that you do do. tseng, could you take a glance at this sometime today and let me know what you think? It's basically using the dlloader and manually relinking everything. Tom, I'm already on the xfree alias -- no need to CC me in addition. Hi, two things. First, has anyone taken a shot at adding the build-specific fixes here to the makefile? This would seem a bit cleaner to me.. the patch could be applied conditionally, but when the .so is linked properly, the dlloader should kick in and work properly for *everyone*, not just explicit dlloader-server users. Second, I'd like to do something a bit different on enabling this, vs USE=ppc64. I'd like to make a more generic USE=dlloader bit, and take out the current USE=pie logic that has hardened users so horribly confused. Counter-thoughts? I hate conditionally applied patches. They're unsuitable for upstream, and that's the real goal here -- taking maintenance of an ever-growing set of patches off our hands. well at least the "good" news is the larger portion of the ppc64 xorg patch is already upstream in cvs. The "bad" news is if someone wants to convince xorg to obsolete their elf loader and just make so's across the board on linux, then they've got work to do upstream. I think it's the "obvious" thing to do, but it's unknown to me how that's viewed upstream. adding a USE flag for dlloader doesn't make much sense to me. Anyway I will add time is short here for this to make 2004.2 so let's please not get too caught up in technical discourse. Plan here is: 1) dlloader is also used on hardened, thus discussions about the USE flag. Currently USE=pie builds .so's, we're going to move that to USE=dlloader. 2) Your stuff will get in as-is (or close) for now. Later on, it would be helpful to hack it into a more friendly form. I plan to add 6.7.0-r2 late tonight as well -- we can probably do the hacking in that while it's still ~arch. If you follow upstream work, in particular the "debrix" project at freedesktop.org, you'll see that work to switch the default to dlloader is already under way. I've committed this patch. I have a bad feeling about -rpath though, see these differences IRT $ROOT:
+ ld -rpath /usr/X11R6/lib/modules/drivers -shared -o ati_drv.so ati_drv.so.orig radeon_drv.so atimisc_drv.so fbdev_drv.so r128_drv.so vga_drv.so
+ ld -rpath /usr/X11R6/lib/modules/drivers -shared -o nv_drv.so nv_drv.so.orig fbdev_drv.so vga_drv.so
+ ld -rpath ${ROOT}/usr/X11R6/lib/modules/extensions -shared -o libglx.so libglx.so.orig libGLcore.so
+ ld -rpath ${ROOT}/usr/X11R6/lib/modules/extensions -shared -o libdri.so libdri.so.orig libglx.so
BTW -- if any ppc64 or X person thinks that is wrong, feel free to commit the change. I'm going out of town this weekend. fix is in portage in -r2 Thanks Yuta! Probably some further work to be done here but I'll log in a different bug ... I have the mga driver built now.. but have an unresolved symbol I need to track down.... in the meantime, stick a fork in it ... works on g5! |