Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 43177 - (X) xfree-4.3.99.902-r2 and xorg-x11 startx fails with duplicate symbol in libbitmap.a
Summary: (X) xfree-4.3.99.902-r2 and xorg-x11 startx fails with duplicate symbol in li...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High critical (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
: 49708 51342 51499 52061 54308 56316 62023 62796 75507 96622 107008 113636 113987 114185 116479 137539 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-28 00:43 UTC by Terje Bergström
Modified: 2006-06-22 00:27 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
xorg-x11 version of libbitmap.a with duplicate symbol problem (xfree-notworking,7.62 KB, application/octet-stream)
2004-04-12 08:24 UTC, Terje Bergström
Details
xfree86 4.3.0-r5 version of libbitmap.a (xfree-working,6.39 KB, text/plain)
2004-04-12 08:26 UTC, Terje Bergström
Details
emerge info result (EmergeInfo.txt,3.00 KB, text/plain)
2004-06-18 09:09 UTC, Greisberger Christophe
Details
XFree log (XFree86.0.log,3.99 KB, text/x-log)
2004-06-18 09:10 UTC, Greisberger Christophe
Details
Patch to allow xorg-x11 to build with hardened gcc (xorg-x11-hardenedgcc.patch,1.34 KB, patch)
2004-07-31 08:07 UTC, Kevin F. Quinn (RETIRED)
Details | Diff
Revised patch to build xorg-11 with hardened gcc using solar's suggested ssp & pie detection method (xorg-x11-hardenedgcc.patch,2.86 KB, patch)
2004-07-31 14:10 UTC, Kevin F. Quinn (RETIRED)
Details | Diff
hardened build patch as above, small correction (xorg-x11-hardenedgcc2.patch,2.89 KB, patch)
2004-08-05 01:37 UTC, Kevin F. Quinn (RETIRED)
Details | Diff
output of emerge info (emerge.info,2.45 KB, text/plain)
2004-08-31 11:19 UTC, Bernd Waibel
Details
set "-fno-pie" for modules, in xorg-6.8.0 (pie-only.patch,1.09 KB, patch)
2004-09-16 23:09 UTC, Kevin F. Quinn (RETIRED)
Details | Diff
set "-fno-pie" for modules. in xorg-6.8.0 (right way round, this time) (pie-only2.patch,1.09 KB, patch)
2004-09-18 06:26 UTC, Kevin F. Quinn (RETIRED)
Details | Diff
Xorg.0.log from elfloader patch above (xorglog-errors-debug.bz2,30.66 KB, application/octet-stream)
2004-09-22 11:42 UTC, Kevin F. Quinn (RETIRED)
Details
Xorg.0.log from elfloader patch above (xorglog-errors-debug.bz2,30.66 KB, application/octet-stream)
2004-09-22 11:42 UTC, Kevin F. Quinn (RETIRED)
Details
Same log, uncompressed (xorglog-errors-debug,489.04 KB, text/plain)
2004-09-22 22:50 UTC, Kevin F. Quinn (RETIRED)
Details
This patch fixes the dulicate symbol problem (patch01.diff,2.89 KB, patch)
2004-11-27 03:41 UTC, Vincenzo Romano
Details | Diff
emerge --info (emerge--info,2.01 KB, application/octet-stream)
2004-11-27 06:01 UTC, Vincenzo Romano
Details
Error messages (Errors,7.26 KB, text/plain)
2004-12-25 08:59 UTC, runlevel0
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terje Bergström 2004-02-28 00:43:30 UTC
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.
Comment 1 Markus Wagner 2004-03-08 04:48:23 UTC
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.
Comment 2 Joe McCann (RETIRED) gentoo-dev 2004-03-11 10:10:18 UTC
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"
Comment 3 Donnie Berkholz (RETIRED) gentoo-dev 2004-03-21 12:04:06 UTC
Please attach /var/log/XFree86.0.log

Also, can you reproduce this with 4.3.0?
Comment 4 Donnie Berkholz (RETIRED) gentoo-dev 2004-03-21 12:15:14 UTC
Nevermind that last comment about 4.3.0, I just read more closely "This problem did not occur with the stable xfree ebuild"
Comment 5 Andrew Bevitt 2004-03-26 14:33:14 UTC
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. 
Comment 7 Andrew Bevitt 2004-03-26 14:54:56 UTC
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.
Comment 8 John Richard Moser 2004-03-27 13:13:20 UTC
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"
Comment 9 Terje Bergström 2004-03-28 05:31:09 UTC
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.
Comment 10 Donnie Berkholz (RETIRED) gentoo-dev 2004-04-11 17:38:23 UTC
Hardened guys, everyone I can find reporting this has a hardened install. Can you help?
Comment 11 Christopher Bock 2004-04-11 17:55:10 UTC
I got the same Problem
with hardened and xorg-x11
Comment 12 Brandon Hale (RETIRED) gentoo-dev 2004-04-11 20:22:27 UTC
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.
Comment 13 Terje Bergström 2004-04-12 08:24:29 UTC
Created attachment 29146 [details]
xorg-x11 version of libbitmap.a with duplicate symbol problem
Comment 14 Terje Bergström 2004-04-12 08:26:01 UTC
Created attachment 29147 [details]
xfree86 4.3.0-r5 version of libbitmap.a
Comment 15 Terje Bergström 2004-04-12 08:26:16 UTC
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.
Comment 16 solar (RETIRED) gentoo-dev 2004-04-12 08:48:49 UTC
Brandon is wise.
Comment 17 Christopher Bock 2004-04-12 09:18:12 UTC
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 :-)
Comment 18 Andrew Bevitt 2004-04-12 19:26:04 UTC
Chris,

Are you saying that you are using hardened-gcc and xorg successfully, or that you are using just a normal gcc implementation? 
Comment 19 Brandon Hale (RETIRED) gentoo-dev 2004-04-13 16:19:14 UTC
Show of hands, anyone who hasnt done anything with hardened/-fPIC and still have a problem? Thanks.
Comment 20 Terje Bergström 2004-04-15 10:30:14 UTC
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.
Comment 21 Brandon Hale (RETIRED) gentoo-dev 2004-04-15 13:06:56 UTC
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.
Comment 22 Andrew Bevitt 2004-05-03 05:06:20 UTC
*** Bug 49708 has been marked as a duplicate of this bug. ***
Comment 23 Salik 2004-05-06 11:27:04 UTC
Yap, taht was hardened gcc. Now everything works juz great.
Comment 24 Donnie Berkholz (RETIRED) gentoo-dev 2004-05-22 01:02:00 UTC
*** Bug 51499 has been marked as a duplicate of this bug. ***
Comment 25 Donnie Berkholz (RETIRED) gentoo-dev 2004-05-26 20:40:59 UTC
*** Bug 51342 has been marked as a duplicate of this bug. ***
Comment 26 Donnie Berkholz (RETIRED) gentoo-dev 2004-06-08 00:11:54 UTC
*** Bug 52061 has been marked as a duplicate of this bug. ***
Comment 27 solar (RETIRED) gentoo-dev 2004-06-08 05:11:35 UTC
Users using a hardened gcc will have to USE=static untill such a time as upstream resolves problems with the dlloader.
Comment 28 Travis 2004-06-08 06:43:10 UTC
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.
Comment 29 Dave Neuer 2004-06-08 07:28:49 UTC
> 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.
Comment 30 Greisberger Christophe 2004-06-18 09:08:50 UTC
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

Comment 31 Greisberger Christophe 2004-06-18 09:08:50 UTC
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?
Comment 32 Greisberger Christophe 2004-06-18 09:09:47 UTC
Created attachment 33502 [details]
emerge info result
Comment 33 Greisberger Christophe 2004-06-18 09:10:25 UTC
Created attachment 33503 [details]
XFree log
Comment 34 Donnie Berkholz (RETIRED) gentoo-dev 2004-06-20 11:13:27 UTC
*** Bug 54308 has been marked as a duplicate of this bug. ***
Comment 35 Markus Pott 2004-06-20 23:27:24 UTC
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 ?
Comment 36 solar (RETIRED) gentoo-dev 2004-06-21 05:44:59 UTC
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.
Comment 37 JC Francois 2004-06-27 10:38:56 UTC
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...?
Comment 38 Dave Neuer 2004-06-27 21:23:39 UTC
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.
Comment 39 solar (RETIRED) gentoo-dev 2004-06-27 21:49:26 UTC
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.
Comment 40 Aurélien Gouny 2004-07-08 01:02:22 UTC
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
Comment 41 Aurélien Gouny 2004-07-08 01:02:22 UTC
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
Comment 42 Alexander Gabert (RETIRED) gentoo-dev 2004-07-08 08:20:32 UTC
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
Comment 43 Alexander Gabert (RETIRED) gentoo-dev 2004-07-09 05:06:08 UTC
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)

Comment 44 Alexander Gabert (RETIRED) gentoo-dev 2004-07-09 05:08:55 UTC
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
Comment 45 John Lyon 2004-07-12 08:05:49 UTC
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.
Comment 46 Donnie Berkholz (RETIRED) gentoo-dev 2004-07-15 11:16:43 UTC
*** Bug 56316 has been marked as a duplicate of this bug. ***
Comment 47 Valmor de Almeida 2004-07-15 16:33:10 UTC
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.
Comment 48 Kevin F. Quinn (RETIRED) gentoo-dev 2004-07-31 08:07:33 UTC
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).
Comment 49 Kevin F. Quinn (RETIRED) gentoo-dev 2004-07-31 08:17:18 UTC
I meant bug #51342 not 54132, above.
Comment 50 solar (RETIRED) gentoo-dev 2004-07-31 08:52:09 UTC
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.
Comment 51 Kevin F. Quinn (RETIRED) gentoo-dev 2004-07-31 14:10:05 UTC
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.
Comment 52 solar (RETIRED) gentoo-dev 2004-08-01 01:42:01 UTC
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.
Comment 53 Travis Tilley (RETIRED) gentoo-dev 2004-08-04 09:17:45 UTC
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.
Comment 54 Travis Tilley (RETIRED) gentoo-dev 2004-08-04 12:25:10 UTC
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 :)
Comment 55 Kevin F. Quinn (RETIRED) gentoo-dev 2004-08-04 14:34:21 UTC
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).
Comment 56 Travis Tilley (RETIRED) gentoo-dev 2004-08-04 16:47:28 UTC
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. :)
Comment 57 Kevin F. Quinn (RETIRED) gentoo-dev 2004-08-05 01:37:46 UTC
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...
Comment 58 Martin bene 2004-08-05 02:58:57 UTC
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!
Comment 59 Travis Tilley (RETIRED) gentoo-dev 2004-08-08 06:23:09 UTC
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. :/
Comment 60 Travis Tilley (RETIRED) gentoo-dev 2004-08-09 17:38:58 UTC
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 ;)
Comment 61 solar (RETIRED) gentoo-dev 2004-08-10 11:33:25 UTC
Travis,
the source of this patch comes from the PaX Team right?
Comment 62 Travis Tilley (RETIRED) gentoo-dev 2004-08-10 12:03:42 UTC
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)
Comment 63 Travis Tilley (RETIRED) gentoo-dev 2004-08-18 00:38:15 UTC
*** Bug 51342 has been marked as a duplicate of this bug. ***
Comment 64 Kevin F. Quinn (RETIRED) gentoo-dev 2004-08-18 11:08:58 UTC
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?)
Comment 65 Seemant Kulleen (RETIRED) gentoo-dev 2004-08-18 11:21:34 UTC
instead of that, can you all please try the masked xorg-x11?
Comment 66 Travis Tilley (RETIRED) gentoo-dev 2004-08-18 12:41:22 UTC
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.
Comment 67 Kevin F. Quinn (RETIRED) gentoo-dev 2004-08-18 13:17:35 UTC
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.
Comment 68 Kevin F. Quinn (RETIRED) gentoo-dev 2004-08-18 13:36:38 UTC
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.
Comment 69 Kevin F. Quinn (RETIRED) gentoo-dev 2004-08-18 14:25:37 UTC
Quick report - rebuilt xorg-x11-6.7.99-2 with the comment #49 patch applied, and it now works for me.
Comment 70 Kevin F. Quinn (RETIRED) gentoo-dev 2004-08-25 23:51:31 UTC
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.
Comment 71 Bernd Waibel 2004-08-31 11:19:05 UTC
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).
Comment 72 A. Person 2004-09-06 08:17:42 UTC
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.
Comment 73 David Oberlitner 2004-09-06 10:12:58 UTC
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
Comment 74 solar (RETIRED) gentoo-dev 2004-09-08 11:29:59 UTC
*** Bug 62796 has been marked as a duplicate of this bug. ***
Comment 75 Jaco Kroon 2004-09-15 03:48:54 UTC
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.
Comment 76 Jaco Kroon 2004-09-15 10:23:59 UTC
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

Comment 77 Kevin F. Quinn (RETIRED) gentoo-dev 2004-09-16 23:09:32 UTC
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.
Comment 78 A. Person 2004-09-17 15:26:01 UTC
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
Comment 79 solar (RETIRED) gentoo-dev 2004-09-17 17:42:36 UTC
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)
Comment 80 Travis Tilley (RETIRED) gentoo-dev 2004-09-17 18:29:08 UTC
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.
Comment 81 Kevin F. Quinn (RETIRED) gentoo-dev 2004-09-18 06:26:26 UTC
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).
Comment 82 solar (RETIRED) gentoo-dev 2004-09-21 15:52:29 UTC
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
Comment 83 vordhosbn 2004-09-21 21:27:17 UTC
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.
Comment 84 solar (RETIRED) gentoo-dev 2004-09-21 21:53:53 UTC
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).
Comment 85 vordhosbn 2004-09-21 22:35:14 UTC
#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. 
Comment 86 Kevin F. Quinn (RETIRED) gentoo-dev 2004-09-22 11:42:23 UTC
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.
Comment 87 Kevin F. Quinn (RETIRED) gentoo-dev 2004-09-22 11:42:49 UTC
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 88 solar (RETIRED) gentoo-dev 2004-09-22 14:48:22 UTC
Comment on attachment 40178 [details]
Xorg.0.log from elfloader patch above

Please don't attach bin files in bugzilla.
Comment 89 solar (RETIRED) gentoo-dev 2004-09-22 14:57:31 UTC
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
Comment 90 Kevin F. Quinn (RETIRED) gentoo-dev 2004-09-22 22:50:26 UTC
Created attachment 40195 [details]
Same log, uncompressed
Comment 91 Vincenzo Romano 2004-09-23 06:52:01 UTC
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?
Comment 92 Alexander Gabert (RETIRED) gentoo-dev 2004-09-23 19:20:05 UTC
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.
Comment 93 Kevin F. Quinn (RETIRED) gentoo-dev 2004-09-23 22:32:59 UTC
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.
Comment 94 Kevin F. Quinn (RETIRED) gentoo-dev 2004-09-25 05:39:15 UTC
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.
Comment 95 Adam Jackson 2004-09-25 15:03:29 UTC
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.
Comment 96 solar (RETIRED) gentoo-dev 2004-10-03 15:47:43 UTC
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.
Comment 97 Donnie Berkholz (RETIRED) gentoo-dev 2004-10-10 23:52:15 UTC
*** Bug 62023 has been marked as a duplicate of this bug. ***
Comment 98 Vincenzo Romano 2004-11-27 03:40:28 UTC
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.
Comment 99 Vincenzo Romano 2004-11-27 03:41:56 UTC
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
Comment 100 Vincenzo Romano 2004-11-27 06:01:50 UTC
Created attachment 44827 [details]
emerge --info

And this is my emerge --info output.
Hoping all this will help.
Comment 101 Donnie Berkholz (RETIRED) gentoo-dev 2004-11-27 11:11:57 UTC
6.8.0-r4 should work fine.
Comment 102 Steve Egbert 2004-12-20 11:59:01 UTC
Using 2004.3 stage1 approach, this bug still persist.
Comment 103 Andreas Korinek 2004-12-23 10:13:15 UTC
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
Comment 104 José Mata Fernandes 2004-12-23 13:59:55 UTC
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.
Comment 105 José Mata Fernandes 2004-12-23 14:01:26 UTC
i mean 6.8.0-r3 was working just fine...
Comment 106 José Mata Fernandes 2004-12-23 14:56:38 UTC
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 :)
Comment 107 José Mata Fernandes 2004-12-23 15:07:39 UTC
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
Comment 108 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-23 22:49:26 UTC
*** Bug 75507 has been marked as a duplicate of this bug. ***
Comment 109 Tro 2004-12-24 14:16:58 UTC
The patch from comment #97 fixes it for me. I'm using GCC 3.4.3 (unhardened).
Comment 110 runlevel0 2004-12-25 08:59:45 UTC
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...
Comment 111 wim van boven 2004-12-28 16:07:07 UTC
ok, the patch from #97 worked for me aswell
Comment 112 marco 2005-01-06 02:29:14 UTC
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.
Comment 113 marco 2005-01-06 03:14:02 UTC
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 ;-)
Comment 114 Tro 2005-01-06 07:08:34 UTC
marco: see the patch from comment #97. It's usually useful to read the discussion before asking.
Comment 115 marco 2005-01-06 11:57:46 UTC
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.  
Comment 116 J.C. Wren 2005-01-06 20:26:45 UTC
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.
Comment 117 marco 2005-01-07 04:54:13 UTC
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.
Comment 118 solar (RETIRED) gentoo-dev 2005-01-07 06:40:35 UTC
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 119 Jean-Claude Wippler 2005-01-07 09:26:49 UTC
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).
Comment 120 Jean-Claude Wippler 2005-01-07 17:31:46 UTC
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.
Comment 121 solar (RETIRED) gentoo-dev 2005-01-07 22:08:01 UTC
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
Comment 122 Donnie Berkholz (RETIRED) gentoo-dev 2005-01-08 17:09:06 UTC
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.
Comment 123 Kevin F. Quinn (RETIRED) gentoo-dev 2005-01-09 07:59:16 UTC
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).
Comment 124 Jean-Claude Wippler 2005-01-09 12:20:23 UTC
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.
Comment 125 Jean-Claude Wippler 2005-01-10 02:44:55 UTC
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.
Comment 126 Reiner Block 2005-01-19 06:43:07 UTC
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.
--------------------------------------------------------------------------
Comment 127 solar (RETIRED) gentoo-dev 2005-01-19 08:46:47 UTC
x11-base/xorg-x11-6.8.1.901 worked out of the box for me.
Comment 128 Tro 2005-01-19 18:44:25 UTC
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?
Comment 129 solar (RETIRED) gentoo-dev 2005-01-19 18:53:01 UTC
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

Comment 130 Adam Mondl (RETIRED) gentoo-dev 2005-01-19 21:02:11 UTC
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.
Comment 131 Tro 2005-01-20 07:53:40 UTC
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.
Comment 132 Tro 2005-01-23 11:06:40 UTC
xorg-x11-6.8.1.902 worked for me without patches when compiled with gcc-3.3.5.
Comment 133 Adam Jackson 2005-01-24 11:42:57 UTC
*** Bug 79365 has been marked as a duplicate of this bug. ***
Comment 134 frozzy 2005-02-22 12:29:37 UTC
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.
Comment 135 Kevin F. Quinn (RETIRED) gentoo-dev 2005-02-22 13:30:06 UTC
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.
Comment 136 Matan Peled 2005-03-11 13:08:47 UTC
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...)
Comment 137 Rouben Tchakhmakhtchian 2005-03-20 21:16:50 UTC
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?
Comment 138 Donnie Berkholz (RETIRED) gentoo-dev 2005-06-21 21:17:44 UTC
*** Bug 96622 has been marked as a duplicate of this bug. ***
Comment 139 Paulo Eduardo Neves 2005-07-12 14:07:20 UTC
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. 
Comment 140 Donnie Berkholz (RETIRED) gentoo-dev 2005-09-23 10:22:45 UTC
*** Bug 107008 has been marked as a duplicate of this bug. ***
Comment 141 Jakub Moc (RETIRED) gentoo-dev 2005-11-26 09:49:49 UTC
*** Bug 113636 has been marked as a duplicate of this bug. ***
Comment 142 Jakub Moc (RETIRED) gentoo-dev 2005-11-29 23:31:54 UTC
*** Bug 113987 has been marked as a duplicate of this bug. ***
Comment 143 Jakub Moc (RETIRED) gentoo-dev 2005-12-01 13:02:12 UTC
*** Bug 114185 has been marked as a duplicate of this bug. ***
Comment 144 Jakub Moc (RETIRED) gentoo-dev 2005-12-23 04:32:21 UTC
*** Bug 116479 has been marked as a duplicate of this bug. ***
Comment 145 James Lee 2006-02-12 17:32:23 UTC
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. 
Comment 146 solar (RETIRED) gentoo-dev 2006-02-12 19:56:13 UTC
(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?
Comment 147 Jakub Moc (RETIRED) gentoo-dev 2006-06-22 00:27:40 UTC
*** Bug 137539 has been marked as a duplicate of this bug. ***