When running startx, XFree86 bumps into a duplicate symbol error when loading libbitmap.a: 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 This problem did not occur with the stable xfree ebuild, but I need the release candidate to get 1400x1050 screen on Intel 855GM. Reproducible: Always Steps to Reproduce: 1.Run startx 2. 3. Actual Results: XFree fails to start. Expected Results: XFree starts properly.
I can confirm the problem. With and without an Radeon IGP320M 3D patch from bugs.xfree.org (Bug 314). Problem occurs also in 99.14 and 99.16. CFLAGS contain march=athlon-xp, -O2, -pipe, -pomit-frame-pointer and -fPIC. Compiling without -fPIC didn't help.
Also getting this error. Tried emerging after doing hardened-gcc -r Tried without hardened-gcc Recompiled glibc and xfree with minimal flags..still nothing Xfree ebuild x11-base/xfree-4.3.99.902-r2 Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.3-joe) ================================================================= System uname: 2.6.3-joe i686 Intel(R) Pentium(R) 4 CPU 2.60GHz Gentoo Base System version 1.4.3.13p1 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-mcpu=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=pentium4 -O2 -pipe" DISTDIR="/files/distfiles" FEATURES="autoaddcvs ccache cvs sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /home/dst/bmg/gnome-current /home/dst/bmg/bmg_overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib apm avi berkdb breakme cdr crypt cups divx dvb dvd encode esd evo fadd flac foomaticdb gdbm gif gnomedb gtk gtk2 gtkhtml hardened imlib jpeg ldap libg++ libwww lirc mad mikmod mmx motif mozilla moznoirc moznomail mpeg ncurses nls nntp nowin oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang speex sse ssl svga tcltk tcpd tetex threads x86 xfig xine xml2 xv zlib"
Please attach /var/log/XFree86.0.log Also, can you reproduce this with 4.3.0?
Nevermind that last comment about 4.3.0, I just read more closely "This problem did not occur with the stable xfree ebuild"
I really cannot work out what is causing this. I have a few ideas so here goes 1) Are any of you using ulibc as opposed to glibc? 2) Please run : nm /usr/X11R6/lib/modules/fonts/libbitmap.a and post the section about bitmapmod.o it should be the last section. Honestly this really doesnt look like its something wrong in xfree but some other library in the system. I really have no idea where to start though.
All I found on Google: http://www.mail-archive.com/xfree86@xfree86.org/msg03536.html http://gcc.gnu.org/ml/gcc-bugs/2003-06/msg01554.html
One last thought it could be caused by xfree's opengl implementation in combination with non-dri enabled systems. Make sure you are using the right kernel dri and xfree-drm modules.
Same problem. I built with `USE="-hardened -pic -pie" emerge xorg-x11` for xorg-x11-0.0-20040320 snapshot. bluefox@icebox xchatlogs $ emerge --info Portage 2.0.50-r2 (hardened-x86-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.4-grsec) ================================================================= System uname: 2.6.4-grsec i686 Gentoo Base System version 1.4.3.13p1 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -Os -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -Os -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache fixpackages sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/spyderous /usr/local/portage/bmggnome /usr/local/portage/breakmygentoo" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="3ds X aalib alsa avi berkdb cdr composite crypt cups dri dvd flac gif gimpprint gnome gpm gstreamer gtk gtk2 gtkhtml hardened imlib java jbig jpeg justify lcms ldap mikmod mmap mng mozilla mpeg nls nptl offensive oggvorbis openal opengl pam perl pic pie png ppds python qt quicktime readline samba sdl speex spell ssl svga tcltk theora tiff truetype videos wmf x86 xml xml2 xmms xv zlib"
1. I'm using glibc defined by default Gentoo profile. 2. Currently if I try to compile with ebuild after syncing, I get the following error. Probably something's been removed: /usr/sbin/ebuild.sh: line 1291: /var/db/pkg/x11-base/xfree-4.3.99.902-r2/xfree-4.3.99.902-r2.ebuild: No such file or directory So I cannot check what's found in the libbitmap.a. DRI is enabled on my system with XFree86 4.3.0.
Hardened guys, everyone I can find reporting this has a hardened install. Can you help?
I got the same Problem with hardened and xorg-x11
At this time, xorg-x11/xfree cannot be built with -fPIC/hardened-gcc. Please be absolutely sure that hardened-gcc is not active, and that -fPIC/-pie is not in your flags, and try again.
Created attachment 29146 [details] xorg-x11 version of libbitmap.a with duplicate symbol problem
Created attachment 29147 [details] xfree86 4.3.0-r5 version of libbitmap.a
I can now reproduce the same behaviour with xorg-x11. I've tried to do everything possible to make sure that hardened-gcc is not enabled. There just is no documentation about this feature and how to deactivate it, so I can't check. I've used "hcc -r" to restore settings, and unmerged hardened-gcc. Now I'm re-emerging gcc in case that helps. I'll attach nm output of the working and non-working libbitmap.a, as requested earlier by Andrew Bevitt.
Brandon is wise.
I've recompiled gcc,glib,glibc and xorg-x11 but still same problem. So i've recompiled my whole System tonight and now it works.(it was an fresh system...) But that's not the best solution i think :-)
Chris, Are you saying that you are using hardened-gcc and xorg successfully, or that you are using just a normal gcc implementation?
Show of hands, anyone who hasnt done anything with hardened/-fPIC and still have a problem? Thanks.
I was finally able to remove hardened gcc, and from the nm output it looks like the problem does not occur anymore. So it seems to be a hardened-gcc problem.
Ok, allow me to break out my cluestick here: hardened-gcc is a shell script (sed really) that edits the GCC spec file to force default building of Position Independent Code using the CFLAG -fPIC. When you use this in combination with nasty, horrible code (case in point, xfree), you get nasty horrible results. As I've pointed out a few times now, XFree and PIC will just not get along atm, so deactivate hardened-gcc (hcc -r), remove -fPIC from any global CFLAGs, or do whatever to avoid building XFree as PIC.. it won't work. Thanks :) Marking "INVALID" as hardened-gcc is deprecated.
*** Bug 49708 has been marked as a duplicate of this bug. ***
Yap, taht was hardened gcc. Now everything works juz great.
*** Bug 51499 has been marked as a duplicate of this bug. ***
*** Bug 51342 has been marked as a duplicate of this bug. ***
*** Bug 52061 has been marked as a duplicate of this bug. ***
Users using a hardened gcc will have to USE=static untill such a time as upstream resolves problems with the dlloader.
I really don't think you have fixed the original issue of this bug. I have not used hardened gcc -- EVER! For any future person that runs along this bug I recommend you do not emerge xfree/xorg with -fstack-protector nor with -fPIC apparently. Hopefully someday some developer will inadvertently fix this, but until such time, just watch your CFLAGS.
> I really don't think you have fixed the original issue of this bug. I have not used hardened gcc -- EVER! Are you sure you haven't used hardened gcc? What does 'gcc --version' print? I hadn't purposely installed hardened gcc and when I saw that I was running it, I tried to rebuild it (even using USE="-hardened"); it still reported that it was hardened. But at the time of my install I used the hardeded profile. I switched profiles, rebuilt gcc (emerge automatically detected the symbols in hardened glibc and rebuilt any libraries/binaries that depended on them), then rebuilt xfree and all was right w/ the world. However, the original problem I had w/ x.org (undefined symbols related to fbdev) should also be fixed. I can open a new bug for that issue, when I get around to backing up my working xfree installation.
Hi! I did also the mistake to put hardened pic pie... :-/ But I am unable to restore my system..... I tried removing these 3 flags, then # emerge gcc glib xfree I tried # USE="-hardened -pic -pie" emerge gcc glib xfree I tried # USE="" CFLAGS="" emerge gcc glibc xfree It definitely don't worlk anymore...... gcc --version gives me: gcc (GCC) 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # # emerge gcc glibc xfree Calculating dependencies ...done! >>> emerge (1 of 3) sys-devel/gcc-3.3.3-r6 to / >>> md5 src_uri ;-) gcc-3.3.3.tar.bz2 >>> md5 src_uri ;-) gcc-3.3.3-patches-1.3.tar.bz2 >>> md5 src_uri ;-) gcc-3.3.3-branch-update-20040412.patch.bz2 >>> md5 src_uri ;-) protector-3.3.2-2.tar.gz >>> md5 src_uri ;-) gcc-3.3.3-manpages.tar.bz2 >>> md5 src_uri ;-) gcc-3.3.3-piepatches-v8.7.6.tar.bz2 <------- damned [snip] | * 01_all_gcc-3.3.3-v8.7.1-pie-generic.patch.bz2... [ ok ] <----+ * 02_all_gcc-3.3.3-v8.7.1-pie-incompat.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.1-pie-rs6000.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-alpha.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-arm.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-ia64.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-mips.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-parisc.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-sparc.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-sparc64.patch.bz2... [ ok ] * Done with patching I thought I was caused by ccache, so I cleared my cache, no change. Attached, my "emerge info" and XFree.0.log
Hi! I did also the mistake to put hardened pic pie... :-/ But I am unable to restore my system..... I tried removing these 3 flags, then # emerge gcc glib xfree I tried # USE="-hardened -pic -pie" emerge gcc glib xfree I tried # USE="" CFLAGS="" emerge gcc glibc xfree It definitely don't worlk anymore...... gcc --version gives me: gcc (GCC) 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # # emerge gcc glibc xfree Calculating dependencies ...done! >>> emerge (1 of 3) sys-devel/gcc-3.3.3-r6 to / >>> md5 src_uri ;-) gcc-3.3.3.tar.bz2 >>> md5 src_uri ;-) gcc-3.3.3-patches-1.3.tar.bz2 >>> md5 src_uri ;-) gcc-3.3.3-branch-update-20040412.patch.bz2 >>> md5 src_uri ;-) protector-3.3.2-2.tar.gz >>> md5 src_uri ;-) gcc-3.3.3-manpages.tar.bz2 >>> md5 src_uri ;-) gcc-3.3.3-piepatches-v8.7.6.tar.bz2 <------- damned [snip] | * 01_all_gcc-3.3.3-v8.7.1-pie-generic.patch.bz2... [ ok ] <----+ * 02_all_gcc-3.3.3-v8.7.1-pie-incompat.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.1-pie-rs6000.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-alpha.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-arm.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-ia64.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-mips.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-parisc.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-sparc.patch.bz2... [ ok ] * 02_all_gcc-3.3.3-v8.7.5-pie-sparc64.patch.bz2... [ ok ] * Done with patching I thought I was caused by ccache, so I cleared my cache, no change. Attached, my "emerge info" and XFree.0.log À propos, what are "hcc -r" or "hardened-gcc -r" ? I didn't find any such command. Else, any clue?
Created attachment 33502 [details] emerge info result
Created attachment 33503 [details] XFree log
*** Bug 54308 has been marked as a duplicate of this bug. ***
I got the same error. I don't defined "hardened" on my system but my system was also including the hardened-ggc ( by unknown reason ) emerge --unmerge hardened-gcc && emerge gcc will hopefully fix it. Does anybody know's how to find out from where the dependency came from ?
Further note to people that come across this bug in xfree/xorg. No need to attach your fail logs we know the problem exists. Another note.. nothing ever should of depended on the now obsolete hardened-gcc, chances are you installed it and forgot that you did. And or used a set of stages where it was installed by default.
I am experiencing the same duplicate symbol problem. I definitely never deliberately installed gcc-hardened as I didn't even know that it existed before reading this thread. But after running gcc --version I found out it was there. It must be a dependency of another package but which one...?
Even if you never installed hardened gcc on purpose, it may, as solar pointed out, have been installed by default based on the base image you installed. Do a 'ls -l /etc/make.profile' If it points to /usr/portage/profiles/hardened-x86-*, you need to change the link to /usr/portage/profiles/default-x86-*. Then rebuild gcc. When I did this, portage noticed I was changing and checked for libs & software which depended on the special hardened glibc symbols, and rebuilt them automatically, and since then everything seems to work fine for me.
Dont be silly.. No need to change profile based on one package misbehaving. I wish you stop it's disrespecting ;/ ajax said the code would be updated in the future to use the dlloader.. till then there is not much point in everybody posting what we already know about this bug over and over. If you want to post something POST patches please.
For information, I use hardened-sources since about 2 months, with gcc 3.3.3 compiled with +hardened flag, here was my output: "gcc (GCC) 3.3.3 20040412 (Gentoo Hardened Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)" As all of you, i got the same error (libbitmap...), both on xfree and x11-org. I don't have any 'hardened-gcc' package, or 'hcc', and my /etc/make.profile is linked to standard, not hardened. So yesterday, I compiled gcc 3.4.1 with: # USE="-hardened" emerge gcc-3.4.1.ebuild Since that, I have 'gcc --version': "gcc (GCC) 3.4.1 (Gentoo Linux 3.4.1, ssp-3.4-2, pie-8.7.6.3)" Not hardened anymore.... and compiling xfree works fine, and startx works again :) Hope it will help, Aur
For information, I use hardened-sources since about 2 months, with gcc 3.3.3 compiled with +hardened flag, here was my output: "gcc (GCC) 3.3.3 20040412 (Gentoo Hardened Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)" As all of you, i got the same error (libbitmap...), both on xfree and x11-org. I don't have any 'hardened-gcc' package, or 'hcc', and my /etc/make.profile is linked to standard, not hardened. So yesterday, I compiled gcc 3.4.1 with: # USE="-hardened" emerge gcc-3.4.1.ebuild Since that, I have 'gcc --version': "gcc (GCC) 3.4.1 (Gentoo Linux 3.4.1, ssp-3.4-2, pie-8.7.6.3)" Not hardened anymore.... and compiling xfree works fine, and startx works again :) Hope it will help, Aurélien
lets get some things clear here: hcc was a softlink to hardened-gcc sys-devel/hardened-gcc was a shell script with modifications to the $(gcc-config -L)/specs file to add PIE and SSP to the specs. this script was a lazy approach to what we are doing now more successfully integrating: USE="hardened" gcc emerges a gcc that contains an automatic default PIE and SSP building specs file, a specs file is a control file like a config file that drives the different steps of the compiler, see literature for more information about this. sys-devel/hardened-gcc and thus hcc is deprecated, away from cvs and should not be on anyones machina any more found in the wild using gcc with USE="hardened" and emerging XFree is still a hot topic on our list of things to make and do. Hope that is clear by now. Thank you, Alex
different error message here, next i am going to try XFree 14:03:28 [/home/pappy/chroots/chroot001:18719.pts-3.papillon]papillon ~ # /usr/bin/X11/X Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.7 Build Operating System: Linux 2.4.26-py i686 [ELF] Current Operating System: Linux papillon 2.4.26-py #3 Tue Jul 6 21:15:33 CEST 2004 i686 Build Date: 09 July 2004 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri Jul 9 14:03:31 2004 (EE) Unable to locate/open config file Using vt 7 xf86AutoConfig: Primary PCI is 1:0:0 Running "/usr/X11R6/bin/getconfig -X 60700000 -I /etc/X11,/usr/X11R6/etc/X11,/usr/X11R6/lib/modules,/usr/X11R6/lib/X11/getconfig -v 0x1002 -d 0x4c57 -r 0x00 -s 0x1014 -b 0x0509 -c 0x0300" getconfig.pl: Version 1.0. getconfig.pl: Xorg Version: 6.7.0.0. getconfig.pl: 23 built-in rules. getconfig.pl: rules file '/usr/X11R6/lib/X11/getconfig/xorg.cfg' has version 1.0. getconfig.pl: 1 rule added from file '/usr/X11R6/lib/X11/getconfig/xorg.cfg'. getconfig.pl: Evaluated 24 rules with 0 errors. getconfig.pl: Weight of result is 500. New driver is "ati" (==) Using default built-in configuration (53 lines) dlopen: /usr/X11R6/lib/modules/extensions/libglx.so: undefined symbol: __glDDXExtensionInfo (EE) Failed to load /usr/X11R6/lib/modules/extensions/libglx.so (EE) Failed to load module "glx" (loader failed, 7) dlopen: /usr/X11R6/lib/modules/drivers/ati_drv.so: undefined symbol: ATIPreInit (EE) Failed to load /usr/X11R6/lib/modules/drivers/ati_drv.so (EE) Failed to load module "ati" (loader failed, 7) dlopen: /usr/X11R6/lib/modules/drivers/fbdev_drv.so: undefined symbol: fbdevHWEnterVT (EE) Failed to load /usr/X11R6/lib/modules/drivers/fbdev_drv.so (EE) Failed to load module "fbdev" (loader failed, 7) dlopen: /usr/X11R6/lib/modules/drivers/vesa_drv.so: undefined symbol: shadowUpdatePlanar4 (EE) Failed to load /usr/X11R6/lib/modules/drivers/vesa_drv.so (EE) Failed to load module "vesa" (loader failed, 7) dlopen: /usr/X11R6/lib/modules/drivers/vga_drv.so: undefined symbol: vgaHWUnmapMem (EE) Failed to load /usr/X11R6/lib/modules/drivers/vga_drv.so (EE) Failed to load module "vga" (loader failed, 7) (EE) No drivers available. Fatal server error: no screens found 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. # emerge info; gcc -v Portage 2.0.50-r8 (hardened-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.4.26-py) ================================================================= System uname: 2.4.26-py i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2" CHOST="i386-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache debug keeptemp keepwork nostrip sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="berkdb crypt hardened nls opengl pam perl pic pie python readline ssl tcpd x86 zlib" Reading specs from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.3/specs Configured with: /var/tmp/portage/gcc-3.3.3-r6/work/gcc-3.3.3/configure --prefix=/usr --bindir=/usr/i386-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.3/include --datadir=/usr/share/gcc-data/i386-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i386-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i386-pc-linux-gnu/3.3/info --enable-shared --host=i386-pc-linux-gnu --target=i386-pc-linux-gnu --with-system-zlib --enable-languages=c,c++ --enable-threads=posix --enable-long-long --disable-checking --disable-libunwind-exceptions --enable-cstdio=stdio --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.3/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --disable-multilib --enable-__cxa_atexit --enable-clocale=generic Thread model: posix gcc version 3.3.3 20040412 (Gentoo Hardened Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)
from Changelog: 11 Jun 2004; Donnie Berkholz <spyderous@gentoo.org>; -xfree-4.3.99.902-r2.ebuild: Pull version vulnerable to #53226. ... will try next available version in CVS: xfree-4.3.0-r7.ebuild
I have this same problem/bug. It jumped up on me all of a sudden out of nowhere. Here's what I found thus far. Xfree and Xorg I could not get to work correctly, even if I reemerge gcc as non-hardened and then use a non-hardened gcc to build xfree and xorg. Still died. Xorg with USE="hardened pie static" fixed the bitmodmap.a error messages, but introduced another bug: "Using vt 7 (EE) No devices detected. Fatal server error: no screens found 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. Couldnt get a file descriptor referring to the console" This was fixed by switching my Xorg.conf file back to using the included "nv" driver instead of the "nvidia" driver. This gives me back a 2D desktop, but is a horrid solution because I can no longer use my 3D/OpenGL features of my graphics card (so long tuxracer). Hopefully my solution helps some. If I could still use my nvidia modules with a static build somehow, that would probably be an acceptable work-around to most people.
*** Bug 56316 has been marked as a duplicate of this bug. ***
After upgrading from the development-sources kernel 2.6.6 to 2.6.7, X stopped working as described in this bug list. I was indeed using hardened USE flag. The quick fix was to recompile gcc 3.3.3-r6 with USE flag -hardened and after that recompile xfree 3.4.0-r7 (with hardened on but it shouldn't matter). Hope this helps others.
Created attachment 36524 [details, diff] Patch to allow xorg-x11 to build with hardened gcc The attachment is a patch I've created which successfully builds xorg-x11-6.7.0-r2 with hardened gcc on my system. xfree should be the same. The Gentoo hardened gcc enables -fstack-protector and -fpie by default; in normal gcc these options are disabled by default. Some of the X software doesn't cope with the stack protector and pie, as we are all aware. The small changes simply add -fno-stack-protector and -fno-pie to the relevant places - they don't fix the X software itself, so some parts of X remain unprotected. However it's better than building all of X with unhardened gcc, and could help get xorg-x11 out of unstable (I assume it wouldn't be considered stable until it builds and runs successfully on hardened as well). The three small changes are described below. 1) The X build already has changes to allow it to build on OpenBSD (which similarly implements a stack protector). The code in 'imake' for this has already been enabled on gentoo; the '#if defined(__OpenBSD__)' is removed from around the get_stackprotector() function declaration and call in xc/config/imake/imake.c, however it's ineffective. The function checks for the word "propolice" on the output of "gcc -v" - the Gentoo hardened gcc doesn't identify its stack protector as "propolice", but as "ssp". The change I've hacked in here, is to identify that gcc has the stack protector enabled by default by finding the word "Hardened" in the output of "gcc -v". Perhaps finding "ssp" would be better, but I'm not sure and I'm bored of building xorg-x11 for now! This change causes the build to add "-fno-stack-protector" to all the bits that presumably the OpenBSD folks figured didn't work with it on (saves having to work all that out ourselves!). It looked to me like this was supposed to work on gentoo as well; perhaps changes to the output of 'gcc -v' have overtaken the relevant patch (9900_all_4.3.0_propolice-gentoo.patch). For information, the build applies these flags to some 1775 invocations of gcc out of 4973, so hits quite a lot of code. On the up side, 3198 compilations do implement the stack protection etc so it's better than using unhardened gcc for everything! 2) 3) Unfortunately, setting '-fno-stack-protector' is not enough - '-fno-pie' is also needed to get things to work. The other two changes are to add this compiler option to MODULE_GCC_FLAGS1 in xc/config/cf/xorg.tmpl, and to xf86.tmpl for good measure. The affected piece is an imake rule that is invoked for some objects when hardened gcc is detected. I would suggest adding these changes, or something similar, to 9900_all_4.3.0_propolice-gentoo.patch, which is the patch that removes the '#if's from get_stackprotector(). The attachment was made against the patched software created by 'ebuild unpack', so applies on top of the existing patch. Ultimately, of course, this is a workaround not a fix. It is desirable to have xorg building with hardeneded protections throughout, since it forms a major part of the system that is run with elevated priviledges. However that has to be a longer-term goal, realistically involving upstream. Lastly, I notice bug #54132 is closely related to this one (it was marked by spyderous as a dup at some point, but is still "New" so isn't closed). I can't think of a good reason why one would put "-fstack-protector" into the make.conf CFLAGS rather than having hardened gcc. However that aside, it may well be that the fix to imake.c can be tweaked to cater for users applying the ssp patch manually (perhaps matching "ssp" instead of "Hardened", as I mentioned above, would be sufficient).
I meant bug #51342 not 54132, above.
Here's a really simple way to test ssp on all arches/all distro's with gcc installed. if gcc -fno-stack-protector -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-stack-protector"; fi; Same logic can be used for -fpie (but not -pie) -f* it works for.
Created attachment 36535 [details, diff] Revised patch to build xorg-11 with hardened gcc using solar's suggested ssp & pie detection method Revised patch using solar's command to detect ssp, instead of 'gcc -v' output. Also checks for and manages pie independently in a similar fashion. Just to emphasise again, this patch just gets things to build so that they run - it hides the problem rather than fixes it.
Everybody/Somebody please test with this patch. (looking for confirm reports that it does indeed allow xorg to build) Terje, Any chance you want to provide an ebuild.diff to make it eaiser for people to test? I 100% agree with you that it's better to fix the problem vs a work around. But it sure sucks having no X for some people so I welcome your patches and hope they do the trick.
gcc -o bdftopcf -O2 -march=athlon64 -pipe -fno-strict-aliasing -ansi -pedantic -Wno-return-type -w -L../../exports/lib bdftopcf.o -lXfont -lfntstubs -L/usr/lib -lfreetype -lz -lm -Wl,-rpath-link,../../exports/lib /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: ../../exports/lib/libfntstubs.a(errorf.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC ../../exports/lib/libfntstubs.a: could not read symbols: Bad value i get that error with this patch on amd64.
ok, luckily xorg-x11 enables -fPIC where needed and does so after global flags are considered. adding an append-flags -fno-pie to the ebuild after strip-flags and applying this patch allows xorg-x11 to compile non-static with elfloader on amd64. kevin, you rock. thanks :)
I'm not (yet!) completely au fait with ebuild scripts; but I think adding "append-flags -fno-pie" like that will break the build for systems with non-hardened gcc (which will reject -fno-pie as an illegal option). Also putting an append-flags in like that forces -fno-pie throughout the whole build (rather than just in modules). The -fno-pie should have been added automatically where needed; does the following: gcc -fno-pie -S -o /dev/null -xc /dev/null > /dev/null 2>&1 echo $? show "0" your system? The patch assumes that the above command returns 0 when -fno-pie is a valid option - perhaps this is different on amd64, or on gcc 3.3.4. BTW I've just noticed I omitted the "> /dev/null" to the gcc commands in my patch (twice), which I guess will cause spurious output during build on non-hardened gcc systems. I'll upload an update once I've checked it builds on my system (which will take a while, as I'm reduced to a P3 laptop instead of the faster box which now has a dead psu).
amd64 has some very strange -fPIC requirements. plus the addition would be: use amd64 && use !dlloader && append-flags -fno-pie even non-hardened gcc should understand -fno-pie with our patches, but to make this only happen for hardened gcc users, you could change it to: use amd64 && use !dlloader && has_hardened && append-flags -fno-pie my gcc supports -fno-pie, but on amd64 all shared objects need to be PIC or everything breaks. with hardened gcc building binaries as PIE, everything becomes a shared object... bdftopcf is being built PIE, but libfntstubs.a was made with -fno-pie and isnt PIC. comment #51 shows the result: ld refuses to link non-PIC code into a shared library (or PIE executable). so i need to disable building PIE binaries by default and that's what i did... if you have a better solution, i'd like to hear it though. a patch that allows everything to be PIE except what wont work as PIE/PIC would be appreciated. i HATE imake. :)
Created attachment 36801 [details, diff] hardened build patch as above, small correction Adds " > /dev/null" to the commands used to detect ssp/pie. Athough -fno-pie should work on all gcc hosts, I figure it's still good to test for it in case a different C compiler is used. Travis - thanks for explaining the amd64 stuff. I'm still trying to work out exactly what ssp, pic/PIC and pie/PIC do; gcc docs are rather vague, and so far I've only found hand-wavy descriptions which aren't much use. As far as my patch goes, it was simply a matter of noticing something that looked like it was intended to work, but didn't due to a small oversight - it's not a result of in depth understanding of the problem :) BTW I agree about imake - to work anything out I run the ebuild compile, then browse the generated Makefiles, and work back from there...
Just tested the (revised, 2004-07-31) patch on a diskless hardened system, Pentium M CPU. w/o patch: the expected duplicate symbol error w/patch: x works (fbdev X-Server, intel855 Chipset) Test was with x11-base/xfree, not x11-base/xorg-x11 Thanks for your work Kevin!
looks like forcing -fno-pie on amd64 isnt an option. at least the static xdmcp is used by gdm and kdebase, and since it's built non-PIC it cant be used in a PIE executable. *sigh* but this is only a slightly related bug :/ the patch should work flawlessly on x86, the PIC bug should only be an issue for amd64, ppc64, hppa, etc. :/
alright, i have a patch that solves just the propolice problem without messing with PIE/PIC or disabling stack-protector. http://dev.gentoo.org/~lv/give-xorg-some-ssp-lovin.patch that should be good for hardened gcc users and users who are just using -fstack-protector... please test and let me know if i broke anything ;)
Travis, the source of this patch comes from the PaX Team right?
the patch from comment #58 is being committed upstream by ajax, so possibly this bug wont exist at all in the next xorg release. go team! =D i'm still working on the pie bug but that shouldnt hold up getting this patch into gentoo to at least fix the -fstack-protector problem. (the source comes from OpenBSD's XF4 module)
Maybe I misunderstood the purpose of the patch on comment #58, but I applied that to xorg-x11-6.7.0-r2 (x86, gcc 3.3.3) on its own (i.e. without my hack from comment #49) and the duplicate symbol error still occurred. I'll try again in case I did something stupid. (BTW am I right in thinking that "propolice" and "ssp" are the same thing?)
instead of that, can you all please try the masked xorg-x11?
the masked xorg has my patch wrapped in an #ifdef __SSP__, and you still need to append-flags -fno-pie if using the elfloader... ayanami xorg-x11 # fgrep SSP * ayanami xorg-x11 # fgrep no-pie * ayanami xorg-x11 # the masked beta definately wont work without editing.
Just to confirm - unmodified, the masked 6.7.99-2 generates the same error. imake is unmodified, so attempts to find the (OpenBSD) string "propolice" in the "gcc -v" output, which isn't present on Gentoo gcc.
re comment #64; just finished a vanilla emerge, and __SSP__ is defined in xc/programs/Xserver/hw/xfree86/loader/Makefile specifically for xf86syms.o There's an if(ProPoliceSupport) around the relevant definition in the Imakefile, and ProPoliceSupport is defined as Yes in xc/config/cf/host.def, unconditionally set by the ebuild script. I didn't record the build log, but "nm xf86sym.o" shows that __guard and __stack_smash_handler are defined so that happened correctly.
Quick report - rebuilt xorg-x11-6.7.99-2 with the comment #49 patch applied, and it now works for me.
Update: tried xorg-x11-6.7.0.99.902, but it still fails with the duplicate symbol. Applied patch from comment #49, and xorg works again.
Created attachment 38599 [details] output of emerge info I applied the latest patch in the attachements list to a fresh install of 2004.1 universal cd stage1 and it worked, while without the patch I got the described error. I am running default profile, but use hardened, pic and pie in my USE flags. gcc --version says, it is a hardened gcc (gcc-3.3.4-r1, ssp-3.3.2-2, pie-8.7.6).
I'm trying to apply the patch from comment #55, but I'm not sure how to do it. Can anyone help me out with easy instructions? I'd love to have X again.
How I applied the patch: ebuild /path/to/ebuild unpack cd /var/tmp/portage/appname/work/appname apply patch: http://www.network-theory.co.uk/articles/patchintro.html ebuild /path/to/ebuild compile install qmerge
*** Bug 62796 has been marked as a duplicate of this bug. ***
Right, this problem persists with xorg-x11-6.8.0, adding "append-flags -fno-pie -fno-pic" on line 151 (directly after strip-flags) fixed this for me on x86. I'm not sure whether only one of these will work, but at least I've got X again. No other patches or changes was required. I'll test again with each one of these individually after I've created a quickpkg of the working one. Will report back later.
Yep, works with only -fno-pie too. The remainder of the discussion is probably right in saying that the root of the problem needs to be fixed, I'm afraid I'm not a guru when it gets to this stuff and won't be able to help much (other than testing patches). The patch in #58 doesn't work for me. In fact, it seems to cause exactly the same kind of breakage, albeit on different symbols. So may I recommend using the test suggested earlier in comment #48 to test whether gcc will take -fno-pie and then do the append-flags if it will? Something like: gcc -fno-pie -S -o /dev/null -xc /dev/null >/dev/null 2>&1 && append-flags -fno-pie
Created attachment 39737 [details, diff] set "-fno-pie" for modules, in xorg-6.8.0 Since the Travis' patch in comment #58 was introduced, the stack-protector does not need any patching. However, -fno-pie is still needed on module code until such time as X's loader is fixed. This is better than setting -fno-pie across the whole build - last time I checked 2/3rds of the build are -fpie, 1/3rd -fno-pie. However I haven't tried with other use flag settings; the un-described "dlloader" option in particular failed on a previous build. The patch simply sets '-fno-pie' in MODULE_GCC_FLAGS. It is guarded by "#if HasGcc" for the moment - I don't know when the pie option was introduced, but if it was gcc3 this can be written "#if HasGcc3". Alternatively putting in the compiler test in the previous patch would work. Incidentally, patch 9900_all_4.3.0_propolice-gentoo.patch is now defunct and should be removed.
I tried to use the pie-only.patch with 6.8.0-r1 and I get: Failed Patch: pie-only.patch! I added: epatch /usr/portage/x11-base/xorg-x11/files/pie-only.patch to xorg-x11-6.8.0-r1.ebuild in the patches area. The *.out file says "can't find file to patch", but I've double checked and everything looks like it's in the right place. This is the patching procedure that worked for me with the previous patch. - Grant
due to a recent security bug in xfree/xorg we are calling for testing of xorg-x11-6.8.0-r1 (only) everything else will be obsolete. The dup symbols problems should be resolved within it according to Travis. Please test that (no extra patching should be needed)
hardened gcc still breaks dlloader. i tried it without hardened gcc and it worked great, but with hardened gcc i get unresolved symbols and have to load modules in the config file by hand in the right order.
Created attachment 39853 [details, diff] set "-fno-pie" for modules. in xorg-6.8.0 (right way round, this time) *ahem* I did the diff the wrong way round, before. This is the same change, but adding my changes rather than trying to remove them! Without this, xorg-x11-6.8.0-r1 still generates the duplicate symbol error with hardened gcc (on x86).
This should solve the dup symbol problems without having to filter ssp/pie for the elfloader. -------------------------------------------------------------------------------- [PaX Team] --- elfloader.c.old 2004-08-10 00:12:10.000000000 +0200 [PaX Team] +++ elfloader.c 2004-08-10 00:19:53.000000000 +0200 [PaX Team] @@ -2571,6 +2571,11 @@ [PaX Team] /* Don't add static symbols to the symbol table */ [PaX Team] continue; [PaX Team] +#define ELF_ST_VISIBILITY(v) ((v) & 0x3) [PaX Team] + if (ELF_ST_VISIBILITY(syms[i].st_other) == STV_HIDDEN) [PaX Team] + /* Don't add hidden symbols to the symbol table */ [PaX Team] + continue; [PaX Team] + [PaX Team] switch (ELF_ST_TYPE(syms[i].st_info)) { [PaX Team] case STT_OBJECT: [PaX Team] case STT_FUNC: [PaX Team] for your reference [PaX Team] wait, you had to define STV_HIDDEN too [PaX Team] ah, i did that, ok, so it's last iteration [PaX Team] normally you'd put the define into the proper .h file [PaX Team] go paste that patch as experimental [PaX Team] and if it works, i'll write a cleaner version
im quite confused about what to do here. im having the described error when trying to startx. this is xorg-x11-6.8.0-r1 on an hardened-gcc 3.4.1 system. it sounds like people are getting this version of xorg-x11 to build and run smoothly with all kinds of hardened-gcc versions without removing "too much" of the hgcc fun. this sounds like a fix for me, as i would rather compile as much of the build with hardened flags as possible, but am willing to compromise some portions where practical such that i can actually use X. i have not gathered how to do this from this thread, however, and am requesting more precise instructions. i get the feeling many other people are having the same problem. eg. "apply the patch" isnt good enough :p -- thanks, vord.
Re comment #81 There is no 1 size fits all solution to this/these problem(s) right now. The current suggested fix when using the elfloader is for somebody with a little time to spare that's about to build X to make a patch using what's in comment #80 right now and to not apply any other patches from this thread. If however your building with the dlloader then see http://hardened.gentoo.org/hardenedxorg.xml ajax aims to do a trial run with some hardened specs and will hopefully be resolving the misc bugs in Xorg as he notices them. So as it stands in general using the dlloader without any patches at all is the preferred solution but it's still a work in progress so results may very especially when using 3rd party drivers such as nividias but hey we can't solve that one ever (use nv instead).
#82 indicates that #49+#71 is not the best fix despite it being a fix, and it poses the question: which loader to use? [as does the referenced xml doc]. i do not know how to answer that question; but even if i did, lets say i chose the elfloader, i wouldnt know how to use #80 to provide a fix. so, could you be more specific as to how one would use #80 to provide a fix? i think that would close the thread. this is probably not the right place to dicuss which loader to use, so i could not ask anyone to do that here.
Created attachment 40178 [details] Xorg.0.log from elfloader patch above Tried the alteration above for the elfloader, but it still dies. The duplicate symbol errors are gone - to be replaced with unresolved symbols __GLOBAL_OFFSET_TABLE__ and __i686.get_pc_thunk.bx instead. There's also a bunch of "unsupported type" errors, which relate to __stack_handler, __guard and __GLOBAL_OFFSET_TABLE__ amongst others. Defined STV_HIDDEN as 2, which seems right. The attachment is the (compressed) output with LOADERDEBUG set to 1.
Created attachment 40179 [details] Xorg.0.log from elfloader patch above Tried the alteration above for the elfloader, but it still dies. The duplicate symbol errors are gone - to be replaced with unresolved symbols __GLOBAL_OFFSET_TABLE__ and __i686.get_pc_thunk.bx instead. There's also a bunch of "unsupported type" errors, which relate to __stack_handler, __guard and __GLOBAL_OFFSET_TABLE__ amongst others. Defined STV_HIDDEN as 2, which seems right. The attachment is the (compressed) output with LOADERDEBUG set to 1.
Comment on attachment 40178 [details] Xorg.0.log from elfloader patch above Please don't attach bin files in bugzilla.
This thread is getting rather long. Just want everybody to know that if your getting frustrated with this just take the easy way out and USE=static
Created attachment 40195 [details] Same log, uncompressed
Hello all. I've just hit (again) the head against this bug. I've applied patch #36535 and xorg-x11-6.7.0-r2 started working! I'm running gcc version 3.3.4 20040623 (Gentoo Hardened Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6). Why has that patch been "dashed"? Is there anyone that can post a (sort of) summary on this huge problem?
It is not a huge problem. It is made a "big problem" by people that want both sides of a coin on one side: high security "means: hardened gcc and X" and high video power "means: nvidia closed source drivers" Simply: if you weigh the security higher, use the construction USE=static for building a statically linked executable that is not able to dynamically load video drivers as modules (either as ELF files via elfloader vs. SHARED LIBS via dllloader) any more. If you need speed and high opengl, you cannot use hardened gcc to compile X at the moment because the elf loader breaks under the PAX kernel. Thats how far i've followed this discussion.
Patch #36535 is obsoleted by patch #39853. Most of the stuff patched by the former is obsolete as the stack-protector functionality was fixed properly (see comment #58). See also comment #75. The patches referenced do not "fix" the problem - they help narrow down where the problem lies, but are bodges not fixes. Until the elfloader is fixed properly, the problem remains. As others have said, if someone specifies "hardened" in their USE flags, they expect everything to be built with pic/pie - any workaround that switches either of these off, is violating what the user requested.
For anyone interested in following up what is necessary with the elfloader, and what dlloader is all about, here's what I've determined (starting from a point of substantial ignorance about lots of things, not least elf dynamic linking!). For some this is all obvious and known, but for many it's not; it has taken a while for me to work it all out (I understand now what all the junk was about, in the log I attached previosuly). The "duplicate symbol" error itself is resolved by comment #80; however this just uncovers the real problem, which was previously hidden. The elfloader in Xorg does not have the ability to resolve various types of relocatable symbols that are always generated by pic/pie. On X86 for example, these include R_386_GOT32, R_386_PLT32, R_386_GOTOFF and R_386_GOTPC which are all used - the elfloader only supports the R_386_32 and R_386_PC32 symbol types (which are the trivial types to support). It's a similar story for other architectures. Without support for the GOT/PLT symbol types, chasing the elfloader in X is, IMHO, a waste of time, at least on X86. To sort this out would effectively mean re-engineering quite a bit of stuff from the standard dynamic loader from glibc and wrestling it into the X elfloader. It's quite a bit of work. It might be possible to re-use some of the amd-86/ia64 stuff to manage GOT and PLT lists, but even so it would take a fair amount of effort to get right. Of course, there is already a fully operational, well tested, mature dynamic loader on the system - from glibc that's /lib/ld-linux.so.2. The obvious idea that occurs at this point, is that ideally there would be a programmatic interface to the glibc loader, and the X loader could be modified to use that instead of home-brewing its own loader. Turns out such an interface exists - dlopen(3) et. al. - and this is exactly what the undocumented "dlloader" option is exploiting. In summary, there's little point trying to get the elfloader to work with hardened/pic/pie. The dlloader option is much better, all round.
in response to comment #92, now if only dlloader worked under hardened ;) i'm working on it. i know what the major issue is but i'm trying to shake down all the possible problems before pushing changes.
For those of you who don't know this bug has been solved on another bug. dlloader works and all is good. Just waiting on the patched to his the tree now.
*** Bug 62023 has been marked as a duplicate of this bug. ***
I'm not sure if this patch really fixes the problem. What I can say is that it's working for me since 6.7.0! I got it from here, don't remember exactly where/when. The point is that I have to manually patch the src1 tarball, recalculate size and checksum and then rebuild everything. It would be great to incorporate such a patch in the default patch list.
Created attachment 44813 [details, diff] This patch fixes the dulicate symbol problem Works also in the latest xorg-x11 release, not just 6.7.0
Created attachment 44827 [details] emerge --info And this is my emerge --info output. Hoping all this will help.
6.8.0-r4 should work fine.
Using 2004.3 stage1 approach, this bug still persist.
6.8.0-r4 has this issue on my machine, I am not using hardened, trying to recompile glibc, gcc, binutils and xorg-x11 with USE="-hardened" at the moment
Same problem here. No gcc-hardened. 6.8.0-r4 was working just fine. Now downgrading to r3, i just hoppe it'll work ok again.
i mean 6.8.0-r3 was working just fine...
Ok, downgraded to 6.8.0-r3 and didn't work, same issue.. i am convinced i'm not using gcc-hardened. If i type 'gcc-config -l' i get: [1] i386-pc-linux-gnu-3.3.3 [2] i686-pc-linux-gnu-3.4.1 [3] i686-pc-linux-gnu-3.4.3 * [4] i686-pc-linux-gnu-3.4.3-hardened [5] i686-pc-linux-gnu-3.4.3-hardenednopie [6] i686-pc-linux-gnu-3.4.3-hardenednossp .. so i supose it got, somehow, installed but it's not currently being used. Now i'll unmerge it, re-emerge gcc and glibc and re-emerge xorg-org I'm counting on you guys :)
Anyway, can one explain why i have 'i386-pc-linux-gnu-3.3.3'. If I use gcc-config to choose it, it doesn't gives me an error but just sticks with the gcc-version i was using before. Ex: $gcc-config -l [1] i386-pc-linux-gnu-3.3.3 [2] i686-pc-linux-gnu-3.4.1 [3] i686-pc-linux-gnu-3.4.3 * [4] i686-pc-linux-gnu-3.4.3-hardened [5] i686-pc-linux-gnu-3.4.3-hardenednopie [6] i686-pc-linux-gnu-3.4.3-hardenednossp $gcc-config i386-pc-linux-gnu-3.3.3 * Switching to i386-pc-linux-gnu-3.3.3 compiler ... [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * # source /etc/profile $source /etc/profile $gcc-config -l [1] i386-pc-linux-gnu-3.3.3 [2] i686-pc-linux-gnu-3.4.1 [3] i686-pc-linux-gnu-3.4.3 * [4] i686-pc-linux-gnu-3.4.3-hardened [5] i686-pc-linux-gnu-3.4.3-hardenednopie [6] i686-pc-linux-gnu-3.4.3-hardenednossp Should i report this? PS: Im sorry for the off-topic
*** Bug 75507 has been marked as a duplicate of this bug. ***
The patch from comment #97 fixes it for me. I'm using GCC 3.4.3 (unhardened).
Created attachment 46869 [details] Error messages I have had the same error using xorg-x11-6.8.0-r3 and -r4, both using gcc 3.4.3, unhardened, using USE="-hardened -pic -pie" and alos setting -hardened in /etc/make.conf. I tryied to apply the patch but as there is no file matching the filename on the patch I had to edit it in order to match X11R6.8.0-src1, which failed with an error message and a *.rej. I unmerged xorg-x11, cleaned ccache's cache (ccache -C) and reemerged xorg-x11-6.8.0.-r4 with the same error message. Nasty issue as it affects my laptop, and until I can solve it I won't be able to use it...
ok, the patch from #97 worked for me aswell
After upgrading to xorg-x11-6.8.1.901 I've also experienced this issue. I've never used any hardended Stuff so far. Please tell me if I'm wrong. startx This is a pre-release version of the The X.Org Foundation X11. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the The X.Org Foundation "monolithic tree" CVS repository hosted at http://www.freedesktop.org/Software/xorg/ X Window System Version 6.8.1.901 (6.8.2 RC 1) Release Date: 16 December 2004 X Protocol Version 11, Revision 0, Release 6.8.1.901 Build Operating System: Linux 2.6.9-nitro4 i686 [ELF] Current Operating System: Linux vincent 2.6.9-nitro4 #3 Sun Dec 19 22:20:51 CET 2004 i686 Build Date: 05 January 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 6 11:16:32 2005 (==) Using config file: "/etc/X11/XF86Config" Duplicate symbol __i686.get_pc_thunk.bx in /usr/lib/modules/fonts/libbitmap.a:bitmapmod.o Also defined in /usr/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. Error message: gcc-config -l [1] i686-pc-linux-gnu-3.3.4 [2] i686-pc-linux-gnu-3.4.3 * [3] i686-pc-linux-gnu-3.4.3-hardened [4] i686-pc-linux-gnu-3.4.3-hardenednopie [5] i686-pc-linux-gnu-3.4.3-hardenednossp emerge info Portage 2.0.51-r8 (default-linux/x86/2004.0, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-nitro4 i686) ================================================================= System uname: 2.6.9-nitro4 i686 Intel(R) Celeron(R) CPU 1.70GHz Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jul 20 2004, 01:11:30)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.8.5-r2, 1.5, 1.9.3, 1.6.3, 1.4_p6, 1.7.9 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://mirror.nutsmaas.nl/gentoo/" LDFLAGS="" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync16.de.gentoo.org/gentoo-merged" USE="x86 X Xaw3d aalib acl acpi alsa apm arts audiofile avi berkdb bitmap-fonts cdr crypt cups curl dga directfb divx4linux dvb dvd encode esd ethereal fam fftw flac font-server foomaticdb fortran gdbm ggi gif gphoto2 gpm gps gtk imagemagick imlib ipv6 irmc jabber jack java jikes jpeg kde ladcca lesstif libg++ libwww lirc mad memlimit mikmod mmx motif mpeg mssql mysql nas ncurses nls odbc oggvorbis opengl oss pam pdflibperl plotutils png pnp python qt quicktime readline ruby samba scanner sdl slang snmp speex spell sse sslsvg svga tcltk tcpd tiff truetype truetype-fonts type1-fonts usb wavelan xml xml2 xmms xosd xv xvid zlib" Right now I try to get X working again by emerging xorg-x11-6.8.0-r4.
xorg-x11-6.8.0-r4 is not working either. Which patch should I apply, or could you provide a new ebuild including the patches. Or, please tell me wich version of xorg will work. On my machine trial an error takes much time ;-)
marco: see the patch from comment #97. It's usually useful to read the discussion before asking.
I've read the discussion. And I really don't want to bother you. But since the Xserver is an essential component for all Linux users, wouldn't it be better to have the patch in portage? Anyway, I will try that patch right now. I also have a laptop, with the same compiler and xorg, and never had this issue. Eventually it is some kind of missconfiguration. Don't get me wrong. I appreciate the work, all of you are doing.
So what exactly is the solution here? I've applied the comment #97 patch, and I still have this problem, with 6.8.1.901. Am I supposed to change any USE flags, also? How do I know if I'm actually using hardened gcc? It shows up in gcc-config -l, but I have no idea how to tell if it's being used or not. Or if I want it to be or not. I had a nicely running Xfree system until someone decided that a non-working Xorg would be better. My fault for not more closely reading the 40 items in the emerge -u world list I suppose, but hey, I try to keep a reasonably current system. It was inappropriate to remove the Xfree ebuild. It's very frusterating to do a routine upgrade, and wind up with a defunct system. It takes about 40 minutes to recompile on this system, so play "guess the USE flags" is not a very exciting game. A list of the steps involved in getting around this duplicate symbol bug would be appreciated. The piecemeal information is too disjointed, and interrupt by too many "it worked, it didn't work" comments.
Ok, finally got xorg-x11-6.8.0-r3 working again with the #97-patch applied. But xorg-x11-6.8.1.901 will not compile with the patch. Cool, X again after three days of trial and error.
Non-hardned users please check that your GCC_SPECS is not incorrectly set. echo $GCC_SPECS Somebody goofed up not so long ago and some lucky users ended up loading hardened specs on non hardened boxes.
Comment #116 is right on the dot for me. It was set to hardened.specs, I've edited /etc/profile.env to make it vanilla.specs - is that the right approach? (am using gcc-config 3.4.3, not hardened).
To follow up to my last comment: no, changing GCC_SPECS to vanilla.specs did not help. Nor does a revert to 6.8.0-r4 work. Also tried a "USE=static emerge xorg-x11" (of 6.8.1-901), but that ends in build errors. Add me to the list of people who did an "emerge world" and is now stuck with a non-working X11. Luckily, I can still remote ssh with X11 tunneling. I've been emerging Gentoo for years, but this is the first time that tracking the stable system broke things beyond my control. I hope you folks can figure it out. I'll tag along and emerge new revisions when they come out.
if #116 did the trick then the right fix should be to update gcc-config ; and make sure the GCC_SPECS is unset. Just about everything you have compiled from when you last merged gcc && gcc-config have probably been built hardened. In the end I don't know what's going on with this bug in general. The fixes have been known for some time by our X guys, but they seem to keep putting and taking the patches out. It always works in -* masking but not ~arch. Maybe this will be fixed before it's bithday next month
solar, I don't know either. I thought this had been fixed. I just grepped all the patches I've ever applied for xorg-x11 and xfree for pie and didn't find anything relating to this bug, nor did I see any reference to it in any ChangeLog. Bug #64618 has the dlloader-nonow patch, which I was thinking fixed this too. So were you, apparently, according to what I think comment #94 means. It takes me an hour to read through this to try getting an idea of what the fix is supposed to be and what are just workarounds, but I can tell you that no patch from this bug has ever been applied. I also find it quite odd that this bug was quiet for so long, then suddenly it started cropping up again recently. From 10 Oct. to 27 Nov. this was dead silent, about a month and a half.
Just for the record, I've been applying the 'nonow' patch, nicked from the recent masked builds, into the various ~x86 builds on my hardened systems over the past several months without problem (i.e. it allows the dlloader to work thus avoiding the elfloader problem, which is what this bug is about).
Solar - thx. Ok, I can take out GCC_SPECS and figure out when the last gcc build was. Is there an easy way to re-emerge all compiles since then? Or, if all else fails, I could do a complete recompile - is there a simple way to do this? I don't mind a lengthy rebuild, if that's what it takes.
Success! I unset GCC_SPECS and commented it out in /etc/env.d/05gcc - then did a re-emerge of just gcc and xorg-x11, and X now works again, yippie! I was about to do "emerge -e" for a full rebuild of all 450 packages, but luckily it was not needed after all. Thank you very much for helping me get back on track.
My GCC_SPECS is unset but I got the same error after installing xorg 6.7.0-r3. I did not use hardened gcc and the gcc version is 3.3.5. -------------------------------------------------------------------------- Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.7 Build Operating System: Linux 2.6.9-gentoo-r6 i686 [ELF] Current Operating System: Linux rbnb-linux 2.6.9-gentoo-r6 #7 Mon Dec 20 16:19:50 CET 2004 i686 Build Date: 19 January 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 19 15:17:34 2005 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen1" (0) (**) | |-->Monitor "Monitor1" (**) | |-->Device "ATI Radeon" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard1" (**) FontPath set to "/usr/share/fonts/100dpi,/usr/share/fonts/75dpi,/usr/share/fonts/afms,/usr/share/fonts/artwiz,/usr/share/fonts/CID,/usr/share/fonts/corefonts,/usr/share/fonts/default,/usr/share/fonts/freefont,/usr/share/fonts/intlfonts,/usr/share/fonts/jmk,/usr/share/fonts/lfp-fix,/usr/share/fonts/lfpfonts-var,/usr/share/fonts/local,/usr/share/fonts/misc,/usr/share/fonts/sharefonts,/usr/share/fonts/Speedo,/usr/share/fonts/terminus,/usr/share/fonts/TTF,/usr/local/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/ukr,/usr/share/fonts/unifont,/usr/share/fonts/urw-fonts,/usr/local/share/fonts,/usr/share/fonts,/usr/X11R6/lib/X11/fonts,/usr/share/fonts/cyrillic,/usr/X11R6/lib/X11/fonts/sharefont" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a 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. --------------------------------------------------------------------------
x11-base/xorg-x11-6.8.1.901 worked out of the box for me.
I had no problems with the ebuilds for the recent xorg releases on my Athlon XP system. I do, however, have to constantly apply the patch from comment #97 to get it to work on my P4 system. I've got the same versions of GCC on both machines, same kernel, same Xorg release. In fact, pretty much everything is the same except for the processor and the graphics card. :) Maybe it's a processor thing?
I'm growing sick of these mails, I want to see this bug RESOLVED this week. "recent" is not good enough to give us insight. What version exactly must you still appply patch from comment #97 ? <x11-base/xorg-x11-6.8.1.901
The original problem in this bug has since been fixed in dlloader. Applying the patch in comment 97 addresses a different issue, namely using elfloader on a hardened system which is unsupported. If you are using a hardened toolchain then you should be using a hardened profile which defaults to dlloader.
solar: I started having this problem when I upgraded from 6.8.0 to 6.8.0-r2. All subsequent upgrades required the patch from comment #97. I don't remember exactly, but I think I upgraded from gcc 3.3 to gcc3.4 around that time. Adam Mondl: As you can probably tell a lot of the people don't have hardened systems (or at least there's no indication of this) and still experience this bug. See comment #28, comment #43, comment #101, comment #104, comment #110, comment #124 I guess not having a trace of hardened gcc and still getting this problem is a different bug, since this one's only relevant for hardened systems.
xorg-x11-6.8.1.902 worked for me without patches when compiled with gcc-3.3.5.
*** Bug 79365 has been marked as a duplicate of this bug. ***
Getting this error with xorg-x11-6.8.2 and gcc-3.3.5-r1 (hardened). I've made a small correction to above patch to apply it in emerge xorg-x11 process. just do: emerge -f xorg-x11 cd /usr/portage/distfiles tar -jxvf xorg-x11-6.8.2-patches-0.1.1.tar.bz2 wget http://frozz.republika.pl/9993_x86_6.8.2-allow-gcc-hard.patch cp 9993_x86_6.8.2-allow-gcc-hard.patch /usr/portage/distfiles/patch/ mv xorg-x11-6.8.2-patches-0.1.1.tar.bz2 xorg-x11-6.8.2-patches-0.1.1.tar.bz2.old tar -jcpf xorg-x11-6.8.2-patches-0.1.1.tar.bz2 patch/ cd /usr/portage/x11-base/xorg-x11/ ebuild xorg-x11-6.8.2.ebuild digest emerge xorg-x11 it works for me.
frozzy: if you're trying to have a hardened system, it's much better to use dlloader (add "dlloader" to your use flags), which builds with almost all the "hard" choices. The elfloader is a bad choice for hardened systems; to get the elfloader to work you have to switch off pic/pie (which is what your patch does) which defeats the ultimate point of the exercise.
Just a note for everybody watching this bug: In the latest nVidia driver release (1.0-7167), one of the changelog entries read: * Added Xorg dlloader support. Which means that now we can both enjoy the security of a hardened system, and the 3D/OpenGL power of the closed source nVidia drivers. And there was much rejoicing. (Yay...)
Given the fact that the 1.0-7167 nVidia drivers are masked for ~x86 and they also seem not to work on some older cards and laptops (including mine), perhaps the 6.8.2 release of xorg-x11 should be ~x86 masked as well?
*** Bug 96622 has been marked as a duplicate of this bug. ***
I don't use hardened and after emergeing the last version of xorg, it started to fail. I've solved it recompiling xorg without the -fPIC flag.
*** Bug 107008 has been marked as a duplicate of this bug. ***
*** Bug 113636 has been marked as a duplicate of this bug. ***
*** Bug 113987 has been marked as a duplicate of this bug. ***
*** Bug 114185 has been marked as a duplicate of this bug. ***
*** Bug 116479 has been marked as a duplicate of this bug. ***
As implied by <a href="http://bugs.gentoo.org/show_bug.cgi?id=43177#c128">comment 128</a>, if you're using a hardened toolchain, you should also be using a hardened profile. So, if you are using hardened gcc and a default profile, this bug will still show up on xorg-x11-6.8.2-r6 becuase the default profile does not have the dlloader use flag set as default. You could add dlloader to your use flags as mentioned above, but a more general solution is below. Run 'ls -l /etc/make.profile' to see what your current profile is. If it says that file is NOT a link to /usr/portage/profiles/hardened/<arch>, then X.org will have the same problem as listed above. Run 'rm /etc/make.profile;ln -s /usr/portage/profiles/hardened/<arch>' to change your profile to hardened. Then remerging xorg worked for me.
(In reply to comment #143) Hi guy. I'm not sure what you are doing but it's not the intended hardened defaults. When using a proper hardened-glibc based profile USE=dlloader is set. solar@simple / $ cd $(portageq envvar PORTDIR)/profiles/hardened/ solar@simple hardened $ grep dll . -R ./ppc/make.defaults:GRP_STAGE23_USE="${ARCH} berkdb crypt dlloader hardened nls pam pic readline ssl tcpd zlib userlocales" ./ppc/make.defaults:USE="${ARCH} dlloader ${GRP_STAGE23_USE}" ./x86/2.6/minimal/make.defaults:GRP_STAGE23_USE="${ARCH} crypt dlloader hardened minimal multicall ncurses pic readline zlib" ./x86/2.6/make.defaults:GRP_STAGE23_USE="${ARCH} berkdb crypt readline nls ssl tcpd zlib pam pic hardened dlloader" ./x86/2.6/make.defaults:USE="${ARCH} berkdb crypt dlloader hardened nls pam pic readline ssl tcpd zlib" ./x86/make.defaults:USE="${ARCH} berkdb crypt dlloader hardened nls pam pic readline ssl tcpd userlocales zlib" ./ppc64/make.defaults:USE="${ARCH} berkdb crypt dlloader hardened pam pic readline ssl zlib userlocales" Do you see otherwise?
*** Bug 137539 has been marked as a duplicate of this bug. ***
