Red Hat Bugzilla – Bug 165976
xorg-x11 fails to build on a rawhide system
Last modified: 2007-11-30 17:11:11 EST
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:
undefined reference to `__stack_smash_handler'
undefined reference to `__guard'
collect2: ld returned 1 exit status
make: *** [Xorg] Error 1
complete log attached
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.try to rebuild xorg-x11-6.8.2-45 on a rawhide system
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
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
(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]
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.