I emerged X.org on a new system (~x86) running gcc 3.3.3 w/ propolice. Upon trying to start X, X fails with about 100 unresolved symbols for __guard and __stack_smash_handler in libbitmap.a I re-emerged without -fstack-protector, and results were good. I think you may need to link against the libraries responsible for propolice stuff when building X. Reproducible: Always Steps to Reproduce: 1. emerge xorg-x11 with -fstack-protector in CFLAGS Actual Results: X fails on unresolved symbols Expected Results: X to run
same apparently here.
same here, only with gcc 3.4.0-r4 on amd64. however, at one point this xorg ebuild worked for me... i only needed to add -nopie to it to get it to build properly. i wonder what change broke this.
> [...] at one point this xorg ebuild worked for me [...] exactly. I am using xorg since a while on another machine (an athlon) where I have got -fstack-protector in my CFLAGS and everything worked fine. I am relatively sure that I did not remove it back then when I merged xorg...hum. never mind. ;-)
*** This bug has been marked as a duplicate of 43177 ***
I was not using hardened gcc.
As far as I can see, this problem still exists and is not a dublicate of bug 43177 (which is for xfree, this one is for xorg). Removing -fstack-protector from the ALLOWED_FLAGS-var in the xorg-x11-ebuild is a workaround, but it would probably be better to patch the Makefiles so it only filters out -fstack-protector for libbitmap and compiles the rest with stack-protector.
I know nothing more about this, reassigning to people who hopefully do.
Same problem here but i dont use -fstack-protector. ----- make.conf relevant things ------- CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe -funroll-loops" CHOST="i686-pc-linux-gnu" USE="acl acpi apache2 avi cddb cups curl dga dnd doc dvd encode evo \ ext-zlib fastcgi foomaticdb gb gd gif gimpprint gnomedb gtk2 gtkhtml \ hbci icq imagemagick java javascript jikes jpeg lcms libwww mcal \ md5sum mmx moznoirc mpeg mpeg4 oav objc opengl openssh pda pdflib png \ ppds quicktime radeon samba sse theora tiff transcode truetype \ unicode usb v4l v4l2 virus-scan wmf wxwindows xfs xine xml xml2 xmms \ xv xvid -pie -nopie -alsa" CXXFLAGS="${CFLAGS}" ---------end--------------- ------error message from Xorg------ (==) Using config file: "/etc/X11/xorg.conf" Duplicate symbol __i686.get_pc_thunk.bx in /usr/X11R6/lib/modules/fonts/libbitmap.a:bitmapmod.o Also defined in /usr/X11R6/lib/modules/fonts/libbitmap.a Fatal server error: Module load failure Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining. ------end error message-------- i've also removed the allowed-flag fstack-protector from the ebuild with no change. Some ideas? since 4 days i dont have any x system running... also xfree dont work any longer (see other bug with same message).
I can duplicate the original problem.
Re comment #6 Thats exactly what needs to be done. Or provide the symbols yourself, such as we do for glibc then you wont have to filter anything. Any takers? The file that provides the symbols can be found in portage/sys-devel/gcc/files/3.3.3/ssp.c ; would probably take 5 mins of c hacking and a rainy day to test it all. Note: also -fstack bugs are not really hardened bugs. They belong to the herd which maintains said pkg with a CC: hardened@ In this case this is an xfree/xorg problem. Hardened is just offering any ideas/help when/where we can. Note: Also in a pinch you should also be able to USE=static emerge blah
*** Bug 53787 has been marked as a duplicate of this bug. ***
about comment #8: I was getting that, then I changed profiles from hardened to default, removed 'pic' from USE flags, and recompiled gcc & xorg-x11 Now i got this problem, but i got -fstack-protector, so that could be it, I'll test this now (its like my forth recompile of X on this 900mhz celeron box :(
re: comment 10 - for anyone else looking for that ssp.c file, its under glibc. The first thing i tried here was letting xorg build as normal, but with FEATURES="keepwork". Copied the ssp.c into /var/tmp/portage/xorg-x11-6.7.0-r1/work/xc/lib/font/bitmap/module and added ssp.c/ssp.o to the SRCS/OBJS lines in the makefiles. From there, rebuilt the libbitmap, copied it into /usr/X11R6/lib/modules/fonts, after which it stopped complaining about the __i686.get_pc_thunk.bx So i thought great, problem solved, added the ssp.c and makefile changes to my ebuild and rebuilt it. Then it started complaining about __i686.get_pc_thunk.bx but this time being a duplicate symbol between ssp.a and bitmapmod.o I suppose i could move the patch step to take place after the initial 'make all' then rerun make in that folder, but that is really an ugly hackish way to try to fix this. There must be a better way.
I'm curious, is this going anywhere? Been over a month. Keep on truckin.
No it's at a complete standstill. Thats why some of the dups of this bug have been Closed as INVALID, we can change the status to UPSTREAM if anybody likes. Your best bet to probably get this resolved is to have ajax from the xorg project look at this bug as he is doing X cleanups and is maybe a gentoo user. http://freedesktop.org/~ajax/ ajax if you see this X probably needs to link with -lc Gentoo provides 3 symbols to glibc non standard in order to facilitate the gcc option -fstack-protector/-fstack-protector-all. Those are __guard@GLIBC __stack_smash_handler@GLIBC __guard@GLIBC http://www.trl.ibm.com/projects/security/ssp/ readelf -s /lib/libc.so.6 | grep '\(stack_smash\|guard\)' 296: 00015820 741 FUNC GLOBAL DEFAULT 11 __stack_smash_handler@@GLIBC_2.3.2 720: 0010d264 4 OBJECT GLOBAL DEFAULT 32 __guard@@GLIBC_2.3.2 885: 00015770 161 FUNC GLOBAL DEFAULT 11 __guard_setup@@GLIBC_2.3.2
solar: ajax is a gentoo user. I've been working a little on convincing him to help out some w/ our stuff.
Created attachment 33792 [details, diff] no-ssp for libbitmap, disable anti-PIC option Disclaimer: not thoroughly tested. Also, my own motivations are primarily to get the dlloader bit working. Its still not loading libglx+libGLcore properly however adding the -fno-stack-protector in the Imakefile does seem to do the trick for getting rid of the libbitmap.a thunk.bx complaint. Your mileage can, and probably will, vary.
So ajax, interested in helping?
sure. i'd think this would be a problem for any module that implicitly depends on libc, not just bitmap. also i'm not really sure why it's triggering at all. the X server does link against libc, so i'd think __stack_smash_handler would be in the symbol table. unless of course the metrolink loader isn't capable of dealing with versioned symbols, which is entirely possible. would adding -fno-stack-protector to CFLAGS for the troublesome modules be an acceptable workaround in the meantime?
I must add that this only appeared for me when emerging xorg-x11-6.7.0-r1. xorg-x11-6.7.0 was fine.
Legoguy: Have you tried 6.7.0 with your current toolchain? Note that this bug was filed well before 6.7.0-r1 was around.
Same here as #20 - didn't have a problem with xorg-x11-6.7.0, got the problem after emerging xorg-x11-6.7.0-r1. After upgrading to xorg-x11-6.7.0-r1, though, unmerging xorg-x11-6.7.0-r1, then re-emerging xorg-x11-6.7.0 didn't seem to help. BTW, I DID have '+hardened' in my USE flag before (when xorg-x11-6.7.0 was working). At the moment, neither '+hardened' nor '-hardened' work :(
like i mentioned earlier, this ebuild did work at one time then broke... so lets look at the changes that happened to the ebuild before may 17 (when this bug was filed). Wed May 12 13:33:50 2004 UTC (6 weeks, 2 days ago) by pappy removed hardened-gcc checks this change shouldnt have made a difference, as it just removed the obsolete checks for hardened-gcc. Wed May 5 15:55:45 2004 UTC (7 weeks, 2 days ago) by spyderous Remove our custom SharedLibraryLoadFlags as a workaround until #49038 (fd.o #600) is fixed. i really think this one is it... but i'd feel a tad silly if wrong. Sun Apr 25 22:44:13 2004 UTC (2 months ago) by spyderous Update so gcc-3.4 is respected (#48933). this update just makes a compiler hack not do anything if "`gcc-major-version`" -eq "3" -a "`gcc-minor-version`" -le "2" ok, we can go further back later. can anyone having this problem go into the xorg ebuild and change the following lines: #echo "#define SharedLibraryLoadFlags -shared -Wl,-z,defs" \ # >> config/cf/host.def so that they dont have that # before them?
oh yeah. dont uncomment those lines if you're using binutils 2.15, otherwise you'll run into bug 49038
I don't think the problem necessarily lies with xorg, Travis -- couldn't it also be a toolchain upgrade that happened around that time?
you're right, that didnt help any. i'll test using 3.3.3-r3 instead of 3.4.0-r6 to see if it was a gcc change.
that doesnt help either, so the change that caused this isnt from gcc.
I was just wondering if another component (maybe one of the fonts) could be the issue (sorry if this sounds like an amateur comment - I'm not too fluent with programming languages yet). If so, would posting a listing of recently emerged apps help? BTW, just like ajax said, I tried adding -fno-stack-protector to my CFLAGS in make.conf - no luck at all :( Tried emerging gcc, then xorg-x11, but it didn't seem to fix anything...
I don't know if this will help anyone, but changing my CFLAGS fixed my problems. This is what I had: CFLAGS="-mcpu=i686 -O3 -pipe" I changed that to: CFLAGS="-march=pentium2 -O3 -pipe" I had a +hardened environment before (gcc 3.3.3 and xorg-x11 6.7.0), and it was working perfectly with my former CFLAGS. I'm not really sure what broke it, but after emerging xorg-x11 6.7.0-r1, nothing worked (emerging the old xorg-x11-6.7.0, emerging gcc then xorg, emerging gcc and xorg with -hardened -pie -pic, etc.). Hope this helps someone :)
I have a gentoo system with gcc-3.3.3-r6 and gentoo-dev-sources-2.6.7-r7 and have a similar problems, but the message was: Symbol __guard from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved! The message appear on Xorg.0.log. My cflags are: "-02 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -fomit-frame-pointer -fstack-protector -pipe" After removing -fstack-protector flag, xorg-x11 builds fine.
xfree/xorg is your area tseng. I'm removing hardened (for my own personal/selfish sanity sake) from these xfree/xorg problems. The attached patch sets attachment #33792 [details, diff] sets -march directly so be careful.
Could the problem be that the versioned symbols (see comment 15, I get the same output) are 2.3.2, but glibc now is 2.3.3.20040420 on my system? My last successful install of xfree was on February 14 with 4.3.0-r5. I had glibc 2.3.2-r9 then. Now I get the unresolved symbols with xfree-4.3.0-r5/6 and xorg-x11-6.7.0-r1 when compiling with -fstack-protector. /lib/libc.so.6 seems correct otherwise $ ls -l /lib/libc.so.6 lrwxrwxrwx 1 root root 13 5 jul 12.47 /lib/libc.so.6 -> libc-2.3.3.so
*** Bug 54566 has been marked as a duplicate of this bug. ***
*** Bug 56879 has been marked as a duplicate of this bug. ***
Bug is fixed since xorg-x11 6.8.0. Could be closed. Thanks to the xorg-devs. This was one of my biggest problems!
Got the same problem with xorg-x11-6.8.2-r1. I am using hardened gcc and I have set the dlloader USE flag. What else should I do?
