This almost could have been a reopen of bug #110506, but as I'm not the author of that one, and this is slightly different... The issue is that I have... LDFLAGS="-Wl,-z,now" ...in make.conf. I haven't checked the ebuilds to see if the fix mentioned in bug #110506 is there, but as of... xorg-server-1.0.1 and xf86-video-ati-6.5.7.3 , ...the ebuilds don't filter LDFLAGS as they most likely should. Commenting the LDFLAGS line in my make.conf, after reading bug #110506, and remerging the two ebuilds solved the problem, so filtering LDFLAGS in the ebuild would have avoided the issue. BTW, gcc4 X compiles seem to be working just fine, now. That's new since xorg-x11-6.8.99.15-r4, the last one I had merged, since I couldn't get modular running. Very good work! =8^) (emerge info shouldn't be needed for this one, but it's worth noting I'm running ~amd64, and you have the video driver info above, so you can block that in as working, with gcc4 even. =8^) Duncan
Don't put such flags yourself into make.conf. Filtering '-z now' isn't any real solution, this needs to be fixed properly upstream. *** This bug has been marked as a duplicate of 110506 ***
Reopening due to discussion on gentoo.devel: http://thread.gmane.org/gmane.linux.gentoo.devel/37986/focus=37989 Basically, split bug from the one it was marked duplicate of (bug # 110506), as this one has a tested patch and should be fixed before going stable (because portage prints an instruction which if followed causes X breakage), while the other one is different and will take some time to solve. As suggested, here's the patch: --- xorg-server-1.0.99.903.ebuild 2006-05-13 08:36:22.000000000 -0700 +++ xorg-server-1.0.99.903.ebuild.new 2006-05-14 03:57:03.000000000 -0700 @@ -519,6 +519,9 @@ pkg_setup() { # (#121394) Causes window corruption filter-flags -fweb + # (#116698) breaks loading + filter-ldflags -Wl,-z,now + # Nothing else provides new enough glxtokens.h ewarn "Forcing on xorg-x11 for new enough glxtokens.h..." OLD_IMPLEM="$(eselect opengl show)"
Shrug... Well, I'd still say that setting LDFLAGS="-Wl,-z,now" globally in make.conf is stupid and not a solution, so this problem is self-inflicted... Besides, the lazy-binding related QA message shouldn't recommend such stuff at all.
(In reply to comment #3) I can't honestly disagree with you on either the self-inflicted or the message (tho the message /is/ useful, in general from a security perspective, with this an exception to the general rule), but if the message is going to be there, having something break from following its instructions isn't very good for stable, and the fix is simple enough, so... If there was a way to disable the message... but that's an entirely different can of worms. BTW, it's obvious, but to be complete, I should say the patch was for xorg-server. x86-video-ati hasn't changed as often and I've just killed the ldflags manually for it. I was considering recompiling it against 7.1-rc3's xorg-server anyway, so I'll soon have it tested and will post that patch once I've verified the expected results match RealLife (TM).
Here's the xf86-video-ati patch, now verified to work with an x restart after the remerge. --- xf86-video-ati-6.6.0.ebuild 2006-04-14 10:30:42.000000000 -0700 +++ xf86-video-ati-6.6.0.ebuild.new 2006-05-14 05:06:36.000000000 -0700 @@ -28,4 +28,7 @@ pkg_setup() { if use dri && ! built_with_use x11-base/xorg-server dri; then die "Build x11-base/xorg-server with USE=dri." fi + + # (#116698) breaks loading + filter-ldflags -Wl,-z,now }
Actually seeting -z now on a global level has quite a few advantages. Has a minor disadvantage also, but in the end I don't see it as stupid. Main advantage I see is that when used with -z relro you are yielded with a read-only Global Offset Table. This is why +hardened sets both by default. Anyway I don't see why hardened is on the CC: list here. These are two unique bugs that are similar only but each need unique solutions. Removing hardened from the CC: list.
Fixed, thanks.
*** Bug 146532 has been marked as a duplicate of this bug. ***
