This bug is for any useful information regarding problems or suggestions for 6.7.99.2 source or ebuild. Also, please make any new bugs for 6.7.99.2 unreproduceable in 6.7.0 depend on this. The intent is to have a list of issues to get resolved for 6.8.0.
Doesn't work with USE=doc. I get: tar: /usr/portage/distfiles/X11R6.7.99.2-src6.tar.gz: Cannot open: No such file or directory tar: Error is not recoverable: exiting now tar: Child returned status 2 tar: Error exit delayed from previous errors !!! ERROR: x11-base/xorg-x11-6.7.99.2 failed. !!! Function unpack, Line 388, Exitcode 2 !!! failure unpacking X11R6.7.99.2-src6.tar.gz !!! If you need support, post the topmost build error, NOT this status message. (Temporary?) Solution: Comment out the lines if use doc then ebegin "Unpacking documentation" unpack X11R${PV}-src6.tar.gz unpack X11R${PV}-src7.tar.gz eend 0 fi from src_unpack() (on a side note: Why isn't the 'fi' indented like the rest?)
Builds fine here on x86 and amd64; have tested GL xorgs and nvidias working, have tested video mode and vt switching, and video playback all seem good. I thought this was one tarball for the lot, why are the docs tar.gz's still trying to be unpacked (as per UncleOwens comments above)...
sparc appears to FAIL the build in libGL; specifically, in /var/tmp/portage/xorg-x11-6.7.99.2/work/xc/lib/GL/mesa/sparc because -I paths don't seem to be set up correctly: Compile call in the build has includes thus: gcc -c -ansi -pedantic -Wno-return-type -w -I../../../../exports/include -I../../../../include /extensions -I../../../../extras/Mesa/src -I../../../../extras/Mesa/src/SPARC -I../../../include -I../../../.. -I../../../../exports/include ====================== Error is../../../../extras/Mesa/src/glheader.h:203:32: GL/internal/glcore.h: No such file or directory ======================= And that file is: ../../../../extras/Mesa/include/GL/internal/glcore.h So the include paths need also -I../../../../extras/Mesa/include by whatever means, and as you see from the compiler call, it is not there. The missing file previously was in ./lib/GL/include/GL/internal/glcore.h My guess is Imakefiles need fixing, but I haven't looked any further.
Add sparc to CC list.
i already filed the sparc GL problem at Bug 60305 i did build this snapshot fine on x86/amd64
the keyboard driver will have to be changed to kbd in xorg.conf during install
I'm already doing the keyboard driver change, but I'll make a more robust function due to donnie's valid concerns.
Add myself to CC list. I want to follow along.
ALLOWED_FLAGS should also include: -mtune - because -mcpu is deprecated in gcc 3.4 -fno-stack-protector - because you might use hardened gcc and want to disable this for some perverted reason (also, the stack protector bug in elfloader isnt fixed until gcc defines __SSP__) -fno-stack-protector-all - ditto -fno-pie - ditto, and because the elfloader breaks when built PIC/PIE (though for hardened, dlloader is much preferred) -fno-unit-at-a-time - users might want to disable the new gcc 3.4 unit-at-a-time compilation scheme -m32 - using gcc 3.4 and -march=k8 enables a macro that assumes the output will be 64bit. in order to use -march=k8 with 32bit and not have it break, you need to also add -m32 even if your gcc cant compile 64bit code. *shrug* -m64 - no real reason, but i dont see why not "-mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow -mregparm -mno-app-regs -mapp-regs -msoft-float -mflat -mno-faster-structs -mfaster-structs -mlittle-endian -mbig-endian -mlive-g0 -mcmodel -mno-stack-bias -mstack-bias" might also need to be allowed, but i forget what bugs were fixed by allowing them into flag-o-matic. *also shrug* also, in cflag_setup, there should probably be a 'has_hardened && use !dlloader && use !static && append-flags -fno-pie'. this is because hardened gcc builds everything -fPIE by default and the elfloader breaks horribly if built PIE/PIC. i was working on fixing this problem, but my head started to hurt and i wandered off after a shiny object. dlloader/static doesnt have this problem. has_hardened is from flag-o-matic.
About the keyboard driver change: Even after you changed the Driver to kbd, startup will fail if a line like Option "Protocol" "Standard" is present. It will fail with (**) Option "CoreKeyboard" (**) Keyboard[0]: Core Keyboard (**) Option "Protocol" "Standard" (EE) PreInit failed for input device "Keyboard[0]" (II) UnloadModule: "kbd" According to kbd(4x) this is still a valid option though.
Regarding Comment #10 , I had no problems with that. What I did have problems with was starting up at all. I would see the nvidia logo full screen, which I have never seen before, then a black screen, then my system was hung. I was able to use SysReq to sync, umount and reboot. I am using propolice (-fstack-protector in CFLAGS), and I know this broke 6.7.0 from starting. But it never got this far, the last version would complain about symbols immediately. So I'm recompiling without propolice, I'll report my results here.
Unfortuately compilation is failing on me minus propolice (-fstack-protector in CFLAGS). I'll attach my portage log next, though I imagine it's huge. IMPORTANT: I set CFLAGS on the command line during this emerge, the only difference from below is that it did not have -fstack-protector . Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.3.4, glibc-2.3.3.20040420-r0, 2.6.7-grsec) ================================================================= System uname: 2.6.7-grsec i686 AMD Athlon(TM) XP 1800+ Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -fstack-protector -fomit-frame-pointer -funroll-loops -fprefetch-loop-arrays -pipe -mmmx -msse -m3dnow -mfpmath=sse,387" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fstack-protector -fomit-frame-pointer -funroll-loops -fprefetch-loop-arrays -pipe -mmmx -msse -m3dnow -mfpmath=sse,387" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache notitles sandbox" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ http://gentoo.blueyonder.co.uk ftp://mirror.iawnet.sandia.gov/pub/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X alsa apm avi berkdb cdr chroot crypt dv dvd dvdr encode foomaticdb gdbm gif gnome gpm gtk gtk2 imlib java jpeg kde ldap libg++ libwww mad mikmod mmx motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png pwdb python qt quicktime readline sdl slang spell sse ssl svga tcltk tcpd tiff truetype x86 xml2 xmms xv zlib"
Created attachment 37456 [details] xorg-x11-6.7.99.2 log (LAST 1MB ONLY) Did NOT have -fstack-protector in CFLAGS
from your config log: c++ -m32 -c -I../nurbtess -I../../libutil -I../../include -I../../../../include -I../../../../include/GL -I../../../.. -I../../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -D_EXTENSIONS_ -DLIBRARYBUILD -DNDEBUG -O2 -march=athlon-xp -fstack-protector -fomit-frame-pointer -fprefetch-loop-arrays -pipe -fno-strict-aliasing arc.cc -o unshared/arc.o rm -f arc.o you can see that -fstack-protector is still there in your CXXFLAGS.
It compiles and installs fine here on a dual Athlon. Although the xorg.conf update is wrong. The keyboard driver line is a little confused...
Regards to Comment #14 : D'oh. Okay I tried again, setting CFLAGS and CXXFLAGS on the same command line when I merged. Is this the proper way to do it? My results were the same. I grepped the log this time for fstack and didn't find it anywhere. As a recap, the results are that the Nvidia logo comes up full screen, which I have never seen before. After a few seconds the screen goes black, then the system is hung. I have to use SysReq to sync / remount ro / reboot. Last night, before trying this, I had updated my profile symlink to 2004.2 , but I doubt that would make a difference. So here is my updated info, keep in mind I passed CFLAGS and CXXFLAGS at merge time, the same as below minus -fstack-protector . Portage 2.0.50-r8 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.3.20040420-r0, 2.6.7-grsec) ================================================================= System uname: 2.6.7-grsec i686 AMD Athlon(TM) XP 1800+ Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -fstack-protector -fomit-frame-pointer -funroll-loops -fprefetch-loop-arrays -pipe -mmmx -msse -m3dnow -mfpmath=sse,387" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fstack-protector -fomit-frame-pointer -funroll-loops -fprefetch-loop-arrays -pipe -mmmx -msse -m3dnow -mfpmath=sse,387" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache notitles sandbox" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ http://gentoo.blueyonder.co.uk ftp://mirror.iawnet.sandia.gov/pub/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X alsa apm avi berkdb cdr chroot crypt dv dvd dvdr encode foomaticdb gdbm gif gnome gpm gtk gtk2 imlib java jpeg kde ldap libg++ libwww mad mikmod mmx motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png pwdb python qt quicktime readline sdl slang spell sse ssl svga tcltk tcpd tiff truetype x86 xml2 xmms xv zlib"
the xorg.conf should be modified to remove the 'speedo' module from being loaded im going to file a bug, the i810 driver is b0rked with this release and with xorg-x11-cvs
I fixed the sed'ing of hte keyboard thing yesterday, but you might have not sync'd that in time.
FieldySnuts: Try disabling APIC; If it is enabled in your kernel... Just add: noapic To the boot options line when booting, or recompile if you wish.
Built OK here on x86 athlon-xp and started, once I'd changed the keyboard driver to kbd. This version still ignores my .Xmodmap settings (http://bugs.gentoo.org/show_bug.cgi?id=47243) but it does now keep my custom settings in /usr/X11R6/lib/X11/xkb/symbols/pc/gb, which I copy over from /root/xorg-6.7.99.2/gb, so I'll stick with xorg-x11 and disable (rename) my .Xmodmap's. Nvidia drivers OK and glxgears gives the same 5200 FPS as xfree.
Well, it's lost my custom keyboard settings again, like the last version. I just don't understand why xmodmap doesn't work. Gone back to xfree, which works!
Compile error on PPC (using gcc-3.4.1-r2) In file included from radeon_accel.c:426: radeon_render.c: In function `R100SetupTextureCP': radeon_render.c:389: error: redefinition of 'RADEONMMIO' radeon_render.c:387: error: previous definition of 'RADEONMMIO' was here radeon_render.c: In function `R200SetupTextureCP': radeon_render.c: 701: error: redefinition of 'RADEONMMIO' radeon_render.c: 699: error: previous definition of 'RADEONMMIO' was here
I found a way around my xorg-x11 xmodmap problems. Both xorg and xfree bind Mode_switch to AltGr by default. However, when you use xmodmap with xorg it loses that binding somehow and AltGr becomes just another Alt key (Alt_R). The workaround is to add this line to .Xmodmap: keycode 113 = Mode_switch Mode_switch XFree doesn't need this as it keeps the Mode_switch binding, but with this change to .Xmodmap it works in both xorg and xfree, so my problem is solved. I have now abandoned my custom /usr/X11R6/lib/X11/xkb/symbols/pc/gb settings, which was fun to do but dangerous as I didn't really know what I was doing.
The second time I emerged this xorg-x11 (to get PAM support) it failed: making all in programs/Xserver/hw/dmx/doc... make[6]: Entering directory `/var/tmp/portage/xorg-x11-6.7.99.2/work/xc/programs/Xserver/hw/dmx/doc' rm -f dmx*.html sgmlfmt -f html dmx.sgml || rm -f dmx.html /bin/sh: line 1: sgmlfmt: command not found rm -f _dmx.ps dmx.ps + rm -f dmx.ps + sgmlfmt -f ps dmx.sgml /bin/sh: line 1: sgmlfmt: command not found make[6]: *** [dmx.ps] Error 127 make[6]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.99.2/work/xc/programs/Xserver/hw/dmx/doc' make[5]: *** [all] Error 2 make[5]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.99.2/work/xc/programs/Xserver/hw/dmx' make[4]: *** [hw/dmx] Error 2 make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.99.2/work/xc/programs/Xserver' make[3]: *** [all] Error 2 make[3]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.99.2/work/xc/programs' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.99.2/work/xc' make[1]: *** [World] Error 2 make[1]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.99.2/work/xc' make: *** [World] Error 2 !!! ERROR: x11-base/xorg-x11-6.7.99.2 failed. !!! Function src_compile, Line 608, Exitcode 2 !!! (no error message) The only way I could get it installed was: USE="-doc" emerge xorg-x11 It's looking for sgmlfmt, which I can't find on my system either, but it doesn't tell me what provides it. The ebuild could use a DEPEND="doc? ( something )" clause.
With xorg-x11-6.7.99.2: * using openGL with ati-drivers 3.9.0-r1 crashes X (3.11 drivers do not work with any xorg version for me) * I can no longer get to console. <ctrl><alt><FN> is completely ignored once X starts up (but works before X starts). This problem has persisted even through re-emerging xorg-6.7.0, and still continues with 6.7.99.2 installed yet again.
Re: Joseph, Comment #17: No, the speedo module should not be removed by default. It's still required for use of Speedo fonts. It's easier for everyone to load it and some people to have it be unnecessary than for some people who need it to have it not working immediately.
Re: Peter, Comment #24: sgmlfmt hasn't previously been required even when building with USE=doc. It's a custom tool that should definitely not be needed for us. Incidentally, it's around http://cvsweb.xfree86.org/cvsweb/doctools/. This seems like a pretty clear bug.
Re: Christopher, Comment #22: This is bug #60295.
Re: Malte, Comment #10: This looks like a valid bug.
Re: Peter, Comment #23: Let's continue to follow this and other xkb-related issues on bug #47243 rather than here.
Re: Comment #27: Let's follow this separately on bug #61168.
Re: Comment #29 and Comment #10, the kbd-Option-Standard-stuff: Shall I report the bug upstream to fd.o or is it something Gentoo specific? Re: Comment #26 and Comment #17, the speedo module: I had that module in my xorg.conf (since ages, never used speedo fonts) but it seems like it didn't get built on my box so I got WWs (or EEs?) about a missing module in my X log (until I removed the line). Maybe I'm just missing a prerequisite though, as I already said, I don't really need it.
comment 32, I get the same thing about speedo, I figured it was out of this release, didn't know it was used for anything (nor was sure what it was for), should a bug be filed about it? can anyone using i810 confirm bug 60428? or post saying it works for them?
Comment #33: Regarding bug #60428: After compiling xorg I got the same unresolved symbols. But after a fresh boot, everything was good. :-) I have an i830M using the i810 driver.
Re: comment #32, Malte: KBD: http://freedesktop.org/bugzilla/show_bug.cgi?id=1142 is the kbd bug. SPEEDO: After looking into it a little, neither Speedo fonts nor the Speedo font module are built by default anymore, and there is no option to build them via USE flags at this point in time. Pending a request to do exactly that, you're right. The speedo module should not be listed. This is not a fatal error, however, so I don't see a need to remove it in the ebuild. People can do that for themselves, if they're reading the log.
Note that Bug 46593 keeps this from compiling on sparc32-SMP (SS20-SMP). This does NOT block xorg-x11 because it is a manifestation of a rather uncommon but annoying problem peculiar to SS20-SMP. It does not indicate any problem with xorg. I note it here in the interest of compiling a complete score card.
comment #34, It still gives those errors after a reboot :( Does anyone know anything I can do for bug 60428? Does anyone know what those unresolved symbols actually mean? like if I have some broken libs or something
Works for me now, before it didn't, in comments 11, 12, 13 and 16. Propolice is not breaking it. Good work!
I'm sorry, I now have to take back my last comment. I had a crash (playing quake3), and rebooted. I went to startx, and just like in my other comments, i got the white screen with the nvidia logo for a few seconds, then the screen goes black and my system hangs. SysReq is required to sync, umount and reboot. I was forced to back off to 6.7.0.
built xorg-x11-6.7.99.902 on ia64 with no snags ... seems to run ok by what i can tell over VNC ...
Keeping in mind comments at Bugs 61940, 60305, 61063, and workaround for Comment 36 above, xorg-x11-6.7.99.902 runs on sparc64+Creator, Elite (ffb, afb) graphics and on sparc32+cg6.
xorg-x11-6.7.99.904 works for me. Before it did not. Before, as stated on previous comments, it would throw up a white screen with nvidia logo (I never saw this before), then go black, and then my system would be hung. Interestingly in those cases, it would act up only after a reboot. Well I rebooted in this case, and it is working just fine. Portage 2.0.50-r8 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r0, 2.6.7-grsec) ================================================================= System uname: 2.6.7-grsec i686 AMD Athlon(TM) XP 1800+ Gentoo Base System version 1.4.16 distcc 2.17 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -fstack-protector -fomit-frame-pointer -funroll-loops -fprefetch-loop-arrays -pipe -mmmx -msse -m3dnow -mfpmath=sse,387" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fstack-protector -fomit-frame-pointer -funroll-loops -fprefetch-loop-arrays -pipe -mmmx -msse -m3dnow -mfpmath=sse,387" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache notitles sandbox" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ http://gentoo.blueyonder.co.uk ftp://mirror.iawnet.sandia.gov/pub/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X alsa apm avi berkdb cdr chroot crypt dv dvd dvdr encode foomaticdb gdbm gif gnome gpm gtk gtk2 imlib java jpeg kde ldap libg++ libwww mad mikmod mmx motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png pwdb python qt quicktime readline sdl slang spell sse ssl svga tcltk tcpd tiff truetype x86 xml2 xmms xv zlib"
xorg-x11-6.7.99.904 appears to work on sparc. Keep in mind previous comments about hardened gcc (probably unique to my configurations), kdb+sun-kbd+kernel-2.4.xx anomaly, and sparc32-SMP problems compiling ati drivers (not xorg problem). Latest ttmkfdir eliminates the segment faults when building font scale files.
Removing 61940 so I can close this. It's been open forever, and I have low hopes of 61940 ever getting fixed because it doesn't affect 2.6 kernels.
On that note..
