From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050729 Fedora/1.1-0.2.5.deerpark.alpha2 Firefox/1.0+ Description of problem: ../../programs/Xserver/hw/xfree86/loader/libloader.a(xf86sym.o):(.data+0x124c): undefined reference to `__stack_smash_handler' ../../programs/Xserver/hw/xfree86/loader/libloader.a(xf86sym.o):(.data+0x1254): undefined reference to `__guard' collect2: ld returned 1 exit status make[4]: *** [Xorg] Error 1 complete log attached Version-Release number of selected component (if applicable): xorg-x11-6.8.2-45 How reproducible: Always Steps to Reproduce: 1.try to rebuild xorg-x11-6.8.2-45 on a rawhide system 2. 3. Additional info:
Created attachment 117746 [details] log of the failed build
A quick look at the above, and I'm willing to bet that this is caused due to RPM_OPT_FLAGS changing to include security related compiler flags. According to your log file: RPM_OPT_FLAGS='-O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables' My first complete total guess, is that the X server's loader does not like "-fstack-protector". If this is the case, the short term fix will likely be to either remove the flag from X server compilation, or to remove it from the whole build temporarily. The long term solution, is X11R7, which no longer uses the ELF loader. If we assume the problem above is ELF loader specific, we can assume the dlloader in X11R7 wont have this problem. That saves time over trying to fix the ELF loader. ;o) Also, concerning time scales, we are initiating our modular X rpm development this week, with current guestimates being 2-3 weeks to complete, and begin integrating into Rawhide. I've CC'd Uli and Jakub in case they've got any comments to add that might be useful. Thanks for the report!
-fstack-protector as implemented in rawhide doesn't ever use __stack_smash_handler nor __guard. So it must be xorg doing weirdo things when it sees __SSP__ define... If you are not using dlopen but the hacky X loader, you'd need to ensure __stack_chk_fail is exported from the X server to modules.
Grep for __SSP__ in the sources and remove this code. Send the patch upstream to make it permanent. The __SSP__ code as it exists is for the unsanctioned, crappy, completely buggy propolice patch from IBM some lunatics like OpenBSD and gentoo use. The official patch is different and it must be the only variant supported. Otherwise where will it end? Every moron with his/her own modification to a tool will send configuration options and you'll drown in a sea of #ifdefs.
(In reply to comment #4) > Grep for __SSP__ in the sources and remove this code. Send the patch upstream > to make it permanent. The __SSP__ code as it exists is for the unsanctioned, > crappy, completely buggy propolice patch from IBM some lunatics like OpenBSD and > gentoo use. The official patch is different and it must be the only variant > supported. Otherwise where will it end? Every moron with his/her own > modification to a tool will send configuration options and you'll drown in a sea > of #ifdefs. I'd have to agree with you on that. I'm ripping out the Propolice support from Xorg for rawhide. Once we're sure we got it all, I'll push it upstream. Thanks for the comments guys.
Created attachment 119211 [details] xorg-x11-6.8.2-loader-remove-propolice-junk.patch Patch which resolves this issue for 6.8.2 builds.
Fixed ages ago in monolithic rawhide X builds. We've switched to modular now anyway. Problemo adioso.