On sparc, after modifying ebuild & adding patches to take care of: 1. Bug 60305 2. Bug 60295 3. Make sure to add "-fno-pie -fno-PIE" to CFLAGS because they seem to confuse xorg's loader; And also 4. Modifying xorg.conf to get rid of missing modules (speedo, xtt) 5. Changing xorg.conf to get a Keyboard definition that xorg-x11-6.7.99.2 will accept (driver name change, Protocol problems as noted in Bug 60295) Then, xorg-x11-6.7.99.2 does start up amd initialize. At least, until it tries to use one of those fonts that Bug 60470 kept it from building. The end of the output from "xinit >& /tmp/X" looks like: ======================= [FVWM][scanForPixmap]: <<WARNING>> Couldn't load image from small.install_3d.xpm antaresia: unable to open font "-bitstream-terminal-medium-r-normal--18-140-100-100-c-110-iso8 859-1", trying "fixed".... *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting ============================ (The application triggering this is fvwm2, the window manager. At this point it is trying to start up an xterm.) In any case, it looks as if the failure is related to the fact that on install, xorg could not build the font directories correctly because of the SegFaults as reported in 60470. At least, they look the same. ================================ Possibly relevant: This system is using fontconfig-2.2.2 (and has been for about a week). ================================
Created attachment 37812 [details] Xorg.0.log leading up to the SegFault This is the Xorg.0.log from the session which SegFaulted after the failure to find a font. That failure is not noted in the log; it is in the output from xinit (actually, by way of fvwm2).
It's late; I can't type. It blocks 60292, not 60295.
Bug 60470 is related to ttmkfdir-3.0.9-r1. Try downgrading to 3.0.9.
There's more to this problem than ttmkfdir, it turns out. I see the SegFault during the install process (emerge -kv ...) for a couple fonts: /usr/lib/portage/bin/ebuild.sh: line 1704: 20558 Segmentation fault LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${ROOT}/usr/X11R6/lib" ${ROOT}/usr/X11R6/bin/ttmkfdir -x 2 -e ${ROOT}/usr/share/fonts/encodings/encodings.dir -o ${x}/fonts.scale -d ${x} (I don't know yet which two they are.) But I see this also with xorg-x11-6.7.0-r1, if I look closely. However, xorg-6.7.99.2 itself gets a Segmentation fault way at the end of initialization: Using fvwm2, everythins is set up, and it's trying to get an xterm started. In fact, the xterm does start. But it dies, apparently while trying to write out the first prompt line. With a Creator card (ffb2+), there are lots of other issues, too, but I haven't started sorting everything out yet. And Seemant says he wants to see results from 99.902 instead, so that will slow me down some. (Whiiiine....) Anyway, ttmkfdir is a problem,but I think it's less likely to be a promary cause of the xterm startup problem I see (than I did a day ago).
this may be semi-INVALID. sunffb uses the cfb core, which is violently Composite-unaware. see http://freedesktop.org/bugzilla/show_bug.cgi?id=1117 , but the short answer is, Composite requires Render, and cfb knows nothing about Render. big explosions, babies crying. try disabling Composite in your xorg.conf.
To debug your ttmkfdir segfaults, try adding an "echo ${x}" into the relevant loop. That'll at least get you to the right directory.
This is a "hardened compiler" problem, as noted in my original point 3. libcfb32.a has some assembly code in it, and the XORG build process ignores normal CFLAGS processing when it goes directly to assembler from gcc (gcc -x assembler ...). Consequently, libcfb32.a doesn't load properly, and things go downhill from there. I'll try to find a nice way to patch around this, because I suspect the problem is not limited to libcfb32.a. But I think ultimately this should be addressed in xorg's loader. When I force 'gcc -x assembler -fno-pie -fno-PIE', xorg-6.7.9.902 builds, installs, and runs on sparc, although it seems to have a lot of DRI issues for Creator (ffb) graphics. More on ffb2+ later and probably in a different report. The actual problem reported here seems to be understood, and will in fact effect very few users (possible only me). It is a real problem, but it should not be a show stopper except for people like me who are also testing hardened gcc.
For bookkeeping purposes, I note that libcfb.a shares the problem with libcfb32.a. I don't know about the other libcfb??.a modules because sunffb doesn't use them. I expect they have the problem as well, though. (Actually, it's the combination of xorg-loader + gcc-hardened that does not play well.)
i have a patch to make cfb work under dlloader at http://freedesktop.org/bugzilla/show_bug.cgi?id=1114 . i doubt i'll ever apply it to mainline, in favor of deprecating cfb* for fb, but note that most of the -hardened issues go away under dlloader. that patch makes cfb work on s3virge on x86 (without composite obviously), i'd like to hear how it does on sparc. but you're right, it is a loader issue, and the Right Thing is to use dlloader instead of elfloader.
Add Alexander Gabert to CC list in case he's interested in discussions in which hardened gcc takes a part. Note to pappy: Purely for your information. gcc-hardened is not doing anything wrong.
thanks, looking at it
please test the xorg on sparc with the new X86 fixes for DLLOADER and hardened, TIA, Alex
Alex, Will do, as I sort out the issues. There are two different issues for sparc, I think, although ajax probably has better information. Specifically, 1. xorg+hardened+dlloader; 2. xorg+sunffb has some problems using dlloader because of cfb requirements. (Translating, the driver for the Creator & Elite graphics cards -- sunffb -- uses the context frame buffer modules -- cfb & friends -- which are otherwise obsolete and do not/cannot use the dlloader. They use the xorg loader, and it cannot handle hardened. Ajax of xorg fame should be able to rewrite what I just wrote to make it make sense.) In theory, the first problem is taken care of. Unfortunately, I am about the only sparc person running hardened, and I also have issue 2. So I have to work out a good way to test this for you; I think ajax has an unofficial patch to take care of sunffb+cfb+dlloader, but tracking it down has not been high on my things-to-do list. So please give me a couple days to sort all this out.
the cfb+dlloader bug is: http://freedesktop.org/bugzilla/show_bug.cgi?id=1114 and the patch is: http://freedesktop.org/bugzilla/attachment.cgi?id=667&action=view I've marked it WONTFIX upstream, but I tested it using the cfb mode of the s3virge driver and cfb worked fine under dlloader. the dlloader+hardened fix in the new ebuild should be platform independent.
Got it. I'll tear apart a copy of the ebuild for 6.8.0-r2 to remove current sparc hardened avoidance & to apply this patch, then try a build. I'll try to get to it this week. Alex, if you don't here anything from me in some reasonable amount of time, please remind me that I owe you some testing.
Alex adn others: With the ebuild as of 18.x.04 for xorg-x11-6.8.0-r2, If I modify it as follows: =================================== --- /home0/cvsroot/gentoo-x86/x11-base/xorg-x11/xorg-x11-6.8.0-r2.ebuild 2004-10-18 05:4 6:02.000000000 +0000 +++ /usr/local/portage/x11-base/xorg-x11/xorg-x11-6.8.0-r2.ebuild 2004-10-18 13:57:37.000 000000 +0000 @@ -74,7 +74,7 @@ nokia tektronix the-open-group todd-c-miller x-truetype xfree86-1.0 MIT SGI-B BSD FTL GPL-2" SLOT="0" -KEYWORDS="~x86" +KEYWORDS="~x86 ~sparc" # Need portage-2.0.50_pre9 for `use !foo` DEPEND=">=sys-libs/ncurses-5.1 @@ -139,7 +139,7 @@ # according to ciaranm # And hardened compiler must be softened. -- fmccor, 20.viii.04 sparc) filter-flags "-fomit-frame-pointer" - if use hardened + if use hardened && ! use dlloader then einfo "Softening gcc for sparc" ALLOWED_FLAGS="${ALLOWED_FLAGS} -fno-pie -fno-PIE" @@ -451,7 +451,7 @@ suntcx sunbw2 glint mga tdfx ati savage vesa vga fbdev \ XF86OSCardDrivers XF86ExtraCardDrivers \ DevelDrivers" >> ${HOSTCONF} - if use hardened + if use hardened && ! use dlloader then einfo "Softening the assembler so cfb modules will play nice wi th sunffb" echo "#define AsCmd CcCmd -c -x assembler -fno-pie -fno-PIE" >> ${HOSTCONF} @@ -633,6 +633,14 @@ EPATCH_SUFFIX="patch" \ epatch ${PATCHDIR} cd ${S} + if use sparc && use hardened + then + cd ${S}/programs/Xserver + einfo "Apply hardened fix for afb and cfb" + epatch ${FILESDIR}/afb-cfb-dlloader-fixes.patch + cd ${S} + fi + host_def_setup ============================================ [[The last 'use hardened' should have been 'use dlloader', but for this exercise that doesn't matter]] Then, try to build the package thus: ====================================== FEATURES='keepwork' USE='dlloader dri glx hardened bitmap-fonts insecure-drivers truetype-fonts type1-fonts -doc' ACCEPT_KEYWORDS='~sparc' emerge -Bv xorg-x11 I eventually get a failure that looks like this: ========================================== gcc -mcpu=ultrasparc -O2 -pipe -fno-strict-aliasing -ansi -pedantic -Wno-return-type -w LargePositionIndependentCFlags -I../../../../programs/Xserver/GL/glx -I../../../../programs/Xserver/GL/include -I../../../../programs/Xserver/include -I../../../../exports/include -I../../../../extras/Mesa/include -I../../../../exports/include/X11 -I../../../../programs/Xserver/mi -I../../../../include/extensions -I../../../../include/fonts -I../../../../lib/GL/include -I../../../../programs/Xserver/hw/xfree86 -I../../../.. -I../../../../exports/include -Dlinux -D__sparc__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DRANDR -DXFIXES -DDAMAGE -DCOMPOSITE -DXEVIE -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DDLOPEN_HACK -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DXResExtension -DX_BYTE_ORDER=X_BIG_ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((8) * 100000) + ((0) * 1000) + 0)" -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -D__GLX_ALIGN64 -c global.c gcc: LargePositionIndependentCFlags: No such file or directory make[6]: *** [global.o] Error 1 ================================================== Notice that this happens fairly late in the build -- it's building programs/Xserver/GL Comments or suggestions?
That weird warning flag '-w LargePositionIndependentCFlags ' probably provides a big clue.
donnie@supernova /usr/X11R6/lib/X11/config $ grep LargePositionIndependentCFlags * Library.tmpl:# if defined(LargePICTable) && LargePICTable && defined(LargePositionIndependentCFlags) Library.tmpl: PICFLAGS = LargePositionIndependentCFlags Library.tmpl:# elif defined(LargePositionIndependentCFlags) Library.tmpl: CXXPICFLAGS = LargePositionIndependentCFlags hpLib.rules:#ifndef LargePositionIndependentCFlags hpLib.rules:# define LargePositionIndependentCFlags +Z sun.cf:# define LargePositionIndependentCFlags -KPIC It appears that they may only get set for sparcs on solaris builds but get used on all sparc builds.
To refine this: Only on sparc, and only in Xserver/GL, the Imakefiles contain this bit of logic: ============= #if defined(sparc) || defined(SparcArchitecture) # define LargePICTable YES PICFLAGS = LargePositionIndependentCFlags #endif =========== Which ends up in the Makefile as PICFLAGS = LargePositionIndependentCFlags and eventually, what started out as 'PICFLAGS = -fPIC' in the Makefile gets overridden by a naked 'Large...'
Three comments, eventual failure: ================================ 1. The bandaid for Large... build problem is to put something like if use sparc then einfo "Zapping garbage sparc CFLAG" echo "#define LargePositionIndependentCFlags -fPIC" >> ${HOSTCONF} fi in the 'if use dlloader ; then' block at about 347 in the ebuild; 2. The glx extension gets built as libglx.so, but the symbolic link in ...modules/externsions is left pointing to libglx.a (in /usr/lib/opengl). After fixing this, the extension loads.; 3. The sunffb driver cannot be loaded, problem is the dlopen() unresolved symbol; fails with message: (II) Loading extension GLX (II) LoadModule: "sunffb" <<<<< FAIL HERE (II) Loading /usr/X11R6/lib/modules/drivers/sunffb_drv.so <<<<<<< dlopen: /usr/X11R6/lib/modules/drivers/sunffb_drv.so: undefined symbol: cfbPutImage <<<< It's in libcfb.so (EE) Failed to load /usr/X11R6/lib/modules/drivers/sunffb_drv.so <<<<<< =========================================== Everything in sight seems to have built with '-nonow' ... at least, Xorg itself did, and sunffb did. But some simple tests, not xorg related, seem to indicate that more is required.(NOTE TO PAPPY) For reference: gcc version 3.3.4 20040623 (Gentoo Hardened Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
OK, Here's how to get around that: In the Modules section, add Load "cfb" Load "cfb32" (Although libGL performance is back to just awful for non-DRI graphics.) Notes: ------ (1) I am writing this comment on a U60 from mozilla with xorg-x11 built thus: ============================== ACCEPT_KEYWORDS='~sparc' emerge -pkv xorg-x11 These are the packages that I would merge, in order: Calculating dependencies ...done! [binary R ] x11-base/xorg-x11-6.8.0-r2 (-3dfx) (-3dnow) +bitmap-fonts -cjk -debug +dlloader -dmx -doc +dri +glx +hardened +insecure-drivers -ipv6 (-mmx) +nls +pam -sdk (-sse) -static +truetype-fonts +type1-fonts (-uclibc) -xfs +xprint +xv [1] Total size of downloads: 0 kB Portage overlays: [1] /usr/local/portage ============================= (Maybe I should have used +dms, too. I am confused by the current crop of xorg-x11 USE flags.) (2) As an ugly fix, in /usr/lib/opengl/xorg-x11/extensions, I simply made a link libglx.a -> libglx.so because xorg install did not build and set it up correctly. (3) Here's the Change diff for the xorg-x11-6.8.0-r2 ebuild to get a successful build: =========================================================== --- /homes/home0/cvsroot/gentoo-x86/x11-base/xorg-x11/xorg-x11-6.8.0-r2.ebuild 2004-10-18 05:4 6:02.000000000 +0000 +++ /usr/local/portage/x11-base/xorg-x11/xorg-x11-6.8.0-r2.ebuild 2004-10-18 20:24:58.000 000000 +0000 @@ -74,7 +74,7 @@ nokia tektronix the-open-group todd-c-miller x-truetype xfree86-1.0 MIT SGI-B BSD FTL GPL-2" SLOT="0" -KEYWORDS="~x86" +KEYWORDS="~x86 ~sparc" # Need portage-2.0.50_pre9 for `use !foo` DEPEND=">=sys-libs/ncurses-5.1 @@ -139,7 +139,7 @@ # according to ciaranm # And hardened compiler must be softened. -- fmccor, 20.viii.04 sparc) filter-flags "-fomit-frame-pointer" - if use hardened + if use hardened && ! use dlloader then einfo "Softening gcc for sparc" ALLOWED_FLAGS="${ALLOWED_FLAGS} -fno-pie -fno-PIE" @@ -341,6 +341,11 @@ then echo "#define HardenedGccSpecs YES" >> ${HOSTCONF} fi + if use sparc + then + einfo "Zapping garbage sparc CFLAG" + echo "#define LargePositionIndependentCFlags -fPIC" >> ${HOSTCONF} + fi fi fi @@ -451,7 +456,7 @@ suntcx sunbw2 glint mga tdfx ati savage vesa vga fbdev \ XF86OSCardDrivers XF86ExtraCardDrivers \ DevelDrivers" >> ${HOSTCONF} - if use hardened + if use hardened && ! use dlloader then einfo "Softening the assembler so cfb modules will play nice with sunffb" echo "#define AsCmd CcCmd -c -x assembler -fno-pie -fno-PIE" >> ${HOSTCONF} @@ -633,6 +638,14 @@ EPATCH_SUFFIX="patch" \ epatch ${PATCHDIR} cd ${S} + if use sparc && use dlloader + then + cd ${S}/programs/Xserver + einfo "Apply hardened fix for afb and cfb" + epatch ${FILESDIR}/afb-cfb-dlloader-fixes.patch + cd ${S} + fi + host_def_setup =============================================== The afb-cfb... patch is ajax's unofficial patch verbatim. Anyway, right now I have hardened+dlloader+sunffb running on sparc, and I'll just keep it going on this system to watch what happens.
Comment on attachment 37812 [details] Xorg.0.log leading up to the SegFault Fixed long ago.
Created attachment 42172 [details, diff] Patch to convert 17.x.04 cvs xorg-x11-6.8.0-r2.ebuild into one which will build and run on sparc. For those who like hard copy, here is the patch I ended up using to convert the cvs ebuild to a workable one for sparc+hardened+dlloader. It does not address my libglx.so/libglx.a mismatch, and performance issues suggest that problem is more subtle than just getting the names to match up.
dmx is Distributed Multiheaded X. You don't need it for what you're doing. The stuff below should change into something in probably linux.cf, always applied. + einfo "Zapping garbage sparc CFLAG" + echo "#define LargePositionIndependentCFlags -fPIC" >> ${HOSTCONF} Note that the current 6.8.0-r2 has tons of changes from your current version and isn't quite ready for use at the moment. It should be done in a couple of days. You might want to stick with an ebuild revision 1.18 or earlier if you need something that's working right now.
This was mostly a test for pappy of the hardened patch on sparc, and that seems to be OK. The bit with -fPIC ... was just to keep the configuration process from replacing the existing '-fPIC' in the Makefile with junk. I didn't mean to suggest ..-r2 was perfect; I was just noting that it was easier to keep it running to see what happens, rather than swap it ut.
Just to keep track while I'm playing with xorg-x11. To take care of the LargePositionIndependentCFlags problem with a patch, I made sure all other patches were first applied, including 0430_all_6.8.0-sparc-add-mach64-to-devel-dri-drivers.patch and then did this: ================= --- config/cf/xorg.cf- 2004-10-27 16:26:00.000000000 +0000 +++ config/cf/xorg.cf 2004-10-27 16:27:10.000000000 +0000 @@ -612,6 +612,10 @@ #define DevelDRIDrivers mach64 #endif +#ifndef LargePositionIndependentCFlags +#define LargePositionIndependentCFlags -fPIC +#endif + /* Sparc64 Drivers */ #if defined(OpenBSDArchitecture) && defined(Sparc64Architecture) /* Amiga framebuffer module */ =========================== If linux.cf is a better place, the right place to put the #define is right after the #ifdef SparcArchitecture at line 888. (But this really isn't linux-specific. The last I knew, you can use gcc on Solaris or FreeBSD for building X11R6. And anyone using gcc+dlloader+sparc should run into this problem. Ajax -- comment?)
Latest testing status for xorg-x11-6.8.0-r2 (CVS version from 27.x.04), built with BREAKME='go ahead' \ USE='dlloader dri glx hardened bitmap-fonts insecure-drivers truetype-fonts type1-fonts -doc' \ ACCEPT_KEYWORDS='~sparc' emerge -Bv xorg-x11 =================== 0. (Add ~sparc keyword and add xorg-x11 to packages.unmask) 1. In the ebuild in the sparc-specific portions, change the "if use hardened" tests to "if use hardened && ! use dlloader" 2. Apply ajax's unofficial afb-cfb patch as noted earlier; 3. Apply patch to xorg.cf to fix garbage CFLAG as shown in Comment 26; 4. Apply following experimental patch for testing (not needed): ============================================= --- programs/Xserver/hw/xfree86/drivers/sunffb/Imakefile- 2004-06-16 09:44:00.000000000 +0000 +++ programs/Xserver/hw/xfree86/drivers/sunffb/Imakefile 2004-10-27 20:27:01.000000000 +0000 @@ -19,7 +19,7 @@ VISOPTIONS = -DUSE_VIS ASVISOPTION = AsVISOption GCCVISOPTION = -Wa,$(ASVISOPTION) -#if AsOutputArchSize == 32 +#if AsOutputArchSize == 32 && !defined(LinuxArchitecture) #define FFBCObjectRule(name) @@\ name.o: name.c @@\ ObjectCompile(-mv8 -mtune=ultrasparc \ ========================================== 5. After install, BUILD BY HAND the symbolic link to /usr/lib/modules/extensions/libglx.so thus: libglx.so -> /usr/lib/opengl/xorg-x11/extensions/libglx.so 6. Update xorg.conf because /usr/X11R6/lib seems no longer valid for much of anything. (!!) 7. REBUILD xterm because it had been built with USE='Xaw3d' and that library no longer exists. ================================================================== ================================================================== After all of that, the result is running fine, so far, but obviously the ebuild is not quite ready for general consumption. (Biggest real problem is the libglx.so failure-to-link-up. Everything else is just adding patches and ebuild changes for sparc.) Results reported from Sun Sparc Ultra-2(SMP), Creator(ffb2+), Linux lacewing.inforead.com 2.4.27-sparc-r1 #1 SMP Fri Oct 8 12:31:31 UTC 2004 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux xorg: Build Date: 27 October 2004 Summary: sparc+hardened+dlloader+sunffb seems to work fine, two new patches are essential (the xorg afb-cfb unofficial fix, and the 3-liner to xorg.cf). Ebuild needs minor changes so that sparc+hardened+dlloader does not disable hardening, and to apply the new patches. libglx.so extension must be created properly (unless it already exists because something else is providing it. Which is possible. I would think that is what the USE=glx is for.)
libglx and friends require basically a sed of opengl-update "s:X11R6/::g" because everything in /usr/X11R6/lib is moving to /usr/lib. There are a few other problems still floating around, like a migration for all other packages putting stuff into /usr/X11R6/lib, the opengl-update thing, and a few errors related to the move. For some reason the Xaw3d package seems to sometimes not build the library. See bug #62975.
Nevermind the libglx comment. Looks like opengl-update also needs to be modified for dlloader.
Created attachment 44214 [details, diff] (Unofficial) patch from xorg-x11 to let afb, cfb work with dlloader This is the xorg-x11 patch which allows sunffb+cfb to work with dlloader. According to ajax, only the sparc graphics drivers still use cfb, so the change is needed only for sparc+xorg+dlloader, and dlloader is really only needed for building xorg-hardened. (Without dlloader, xorg+hardened must actually force 'softening'.)
Created attachment 44215 [details, diff] Make sure LargePositionIndependentCFlags is defined to be something meaningful If Mesa is built for the dlloader, its Imake files need something useful in 'LargePositionIndependentCflags'. Without this fix, all they get is the string 'LargePositionIndependentCflags'. The patch puts the definition in 'xorg.cf' because I think the problem is not linux-specific, but rather, gcc-specific.
Created attachment 44221 [details, diff] experimental change to sunffb Imakefile to build with more sane CFLAGS on Linux Currently, when sunffb builds, it goes through a lot of effort to make sure that it does not build a 64-bit version when it shouldn't. This results in a CFLAGS combination '-mcpu=ultrasparc -mv8' which is semantically incoherent with gcc. (Maybe, OK with sun compiler?) It then goes on to ensure that the assembly code will run on ultrasparc, and when everything is put together, it forces the driver NOT to be typed V8+. Consequently, if you build xorg-x11 for ultrasparc, the ONLY part of it which will load on your SS20 is the sunffb driver, and that would be a Bad Idea(tm). This little experimental Imake change disables all that for SparcLinux.
Created attachment 44236 [details, diff] Patch 6.8.0-r4 ebuild to apply 44214, 44215, 44221 and to avoid softening if both hardened & dlloader Patch the xorg-x11-6.8.0-r4.ebuild file, 18.xi.04 version, to apply the xorg-afb/cfb patch, and to apply the LargePositionIndependentCflags fix and the experimental sunffb mod. Also, if both hardened & dlloader are used, do NOT force softening. That combination is a true hardened xorg-x11.
With all patches in place (the three in xorg-x11/files and patch 44236 applied to xorg-x11-6.8.0-r4.ebuild): 1. Assume both opengl-update & xorg-x11 are appropriately unmasked in /etc/portage; 2. Assume gcc is hardened. THEN: BREAKME='for sure' \ FEATURES='keepwork' USE='dlloader opengl hardened bitmap-fonts insecure-drivers truetype-fonts type1-fonts -doc -font-server' \ emerge -Bv xorg-x11 (and then, xmerge -kv xorg-x11, of course) builds the xorg-x11 firefox is using to write this comment -- Thu Nov 18 19:45:45 2004 --> x11-base/xorg-x11-6.8.0-r4
Are those three patches OK to _always_ apply? It looks to me like they are. Please let me know if they aren't.
Ferris: Assuming the above is true, could you please file bugs for the patches at comment #32 and comment #33 at bugs.freedesktop.org, and paste the URLs here?
1. Patch 44214 is always good, is required for dlloader support, and was created by ajax. He does not want to apply it officially because (I think) only Gentoo cares. Otherwise, so far as I know, always apply. 2. Patch 44215 is always good and addresses a real bug in the config files. 3. Patch 44221 is almost mandatory if you use gcc (otherwise, the CFLAGS for sunffb are incoherent). Unfortunately, if you are using a sun compiler with Linux (shouldn't be possible), it is wrong. On balance, I think it should always be applied --- it says that if you are running Linux, you shouldn't both require -v9 architecture and (not -v9) architecture, then let the compiler choose. (The -mv8 flag to gcc is deprecated, anyway.) ============ I'll file these to xorg in a bit.
1. This is the fix for LargePositionIndependentCFlags, applied to xorg.cf as distributed (so line numbers do not match our version). https://bugs.freedesktop.org/show_bug.cgi?id=2072 2. The Imakefile bug for the build of sunffb is here: https://bugs.freedesktop.org/show_bug.cgi?id=2073 As mentioned, 44214 is already an xorg-generated patch.
Fixed in 6.8.0-r4, patchset 0.2.11. We'll continue to follow the patches upstream until something happens.
Ferris, as far as I can tell we're just waiting for https://bugs.freedesktop.org/show_bug.cgi?id=2073 , but this is for the old imake build system. Is this issue fixed in modular?
(In reply to comment #40) > Ferris, as far as I can tell we're just waiting for > https://bugs.freedesktop.org/show_bug.cgi?id=2073 , but this is for the old > imake build system. Is this issue fixed in modular? Yes, this is imake only, and X-modular has no problems with CFLAGS. (The problem with X-modular+sunffb is spelled out in https://bugs.freedesktop.org/show_bug.cgi?id=4890, but I *think* I have some insight into a general solution to that bug. More later.) So, this particular bug is not waiting on anything at all (Gentoo contains the patch for X-monolithic builds, and X-modular has problems, but not this one.)
Thanks, I'll close this one then.
Marking fixed.
