This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 165976 - xorg-x11 fails to build on a rawhide system
xorg-x11 fails to build on a rawhide system
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-15 09:34 EDT by Karsten Hopp
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-23 12:03:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log of the failed build (8.64 MB, text/plain)
2005-08-15 09:35 EDT, Karsten Hopp
no flags Details
xorg-x11-6.8.2-loader-remove-propolice-junk.patch (1.48 KB, patch)
2005-09-23 16:24 EDT, Mike A. Harris
no flags Details | Diff

  None (edit)
Description Karsten Hopp 2005-08-15 09:34:25 EDT
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:
Comment 1 Karsten Hopp 2005-08-15 09:35:42 EDT
Created attachment 117746 [details]
log of the failed build
Comment 2 Mike A. Harris 2005-08-16 18:34:50 EDT
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!
Comment 3 Jakub Jelinek 2005-08-16 18:48:31 EDT
-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.
Comment 4 Ulrich Drepper 2005-08-16 19:01:03 EDT
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.
Comment 5 Mike A. Harris 2005-09-23 15:51:17 EDT
(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.
Comment 6 Mike A. Harris 2005-09-23 16:24:32 EDT
Created attachment 119211 [details]
xorg-x11-6.8.2-loader-remove-propolice-junk.patch

Patch which resolves this issue for 6.8.2 builds.
Comment 7 Mike A. Harris 2005-11-23 12:03:43 EST
Fixed ages ago in monolithic rawhide X builds.  We've switched to
modular now anyway.  Problemo adioso.

Note You need to log in before you can comment on or make changes to this bug.