Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 49038 - xorg-x11 can't resolve some symbols at build time because of server-module structure
Summary: xorg-x11 can't resolve some symbols at build time because of server-module st...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Gentoo X packagers
: 49913 (view as bug list)
Depends on:
Reported: 2004-04-26 08:11 UTC by Travis Tilley (RETIRED)
Modified: 2005-11-13 15:37 UTC (History)
8 users (show)

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

gcc-3.3.3-r3 spec built with binutils- (gcc-3.3.3-,5.15 KB, text/plain)
2004-05-03 06:00 UTC, Torne Wuff
gcc-3.3.3-r3 spec built with binutils- (gcc-3.3.3-,5.12 KB, text/plain)
2004-05-03 06:30 UTC, Torne Wuff

Note You need to log in before you can comment on or make changes to this bug.
Description Travis Tilley (RETIRED) gentoo-dev 2004-04-26 08:11:09 UTC
when I attempt to merge xorg-x11 with binutils and gcc 3.3.3-r3 installed, i get the following error:

gcc -c -O2 -pipe -fno-strict-aliasing  -ansi -pedantic -Wno-return-type -w    -I../.. -I../../exports/include   -Dlinux -D__amd64__ -D_POSIX_C_SOURCE=199309L  -D_POSIX_SOURCE -D_XOPEN_SOURCE                          -D_BSD_SOURCE -D_SVID_SOURCE                             -D_GNU_SOURCE                            -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS  -D_REENTRANT -DXUSE_MTSAFE_API    -DMALLOC_0_RETURNS_NULL  -DXVENDORNAME='"The X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"'    -fPIC XF86Rush.c
rm -f
+ cd .
+ gcc -o ./ -shared -Wl,-z,defs -Wl,-soname, XF86Rush.o -lc
XF86Rush.o(.text+0x11): In function `find_display':
: undefined reference to `XextCreateExtension'
XF86Rush.o(.text+0x2a): In function `find_display':
: undefined reference to `XextFindDisplay'
XF86Rush.o(.text+0x54): In function `find_display':
: undefined reference to `XextAddDisplay'
XF86Rush.o(.text+0x72): In function `close_display':
: undefined reference to `XextRemoveDisplay'
XF86Rush.o(.text+0x120): In function `XF86RushQueryVersion':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0x1a0): In function `XF86RushQueryVersion':
: undefined reference to `_XReply'
XF86Rush.o(.text+0x21d): In function `XF86RushQueryVersion':
: undefined reference to `_XFlush'
XF86Rush.o(.text+0x288): In function `XF86RushLockPixmap':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0x315): In function `XF86RushLockPixmap':
: undefined reference to `_XReply'
XF86Rush.o(.text+0x38c): In function `XF86RushLockPixmap':
: undefined reference to `_XFlush'
XF86Rush.o(.text+0x3f0): In function `XF86RushUnlockPixmap':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0x49e): In function `XF86RushUnlockPixmap':
: undefined reference to `_XFlush'
XF86Rush.o(.text+0x4f0): In function `XF86RushUnlockAllPixmaps':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0x58c): In function `XF86RushUnlockAllPixmaps':
: undefined reference to `_XFlush'
XF86Rush.o(.text+0x5f0): In function `XF86RushSetCopyMode':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0x69e): In function `XF86RushSetCopyMode':
: undefined reference to `_XFlush'
XF86Rush.o(.text+0x700): In function `XF86RushSetPixelStride':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0x7ae): In function `XF86RushSetPixelStride':
: undefined reference to `_XFlush'
XF86Rush.o(.text+0x811): In function `XF86RushOverlayPixmap':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0x915): In function `XF86RushOverlayPixmap':
: undefined reference to `_XFlush'
XF86Rush.o(.text+0x936): In function `XF86RushOverlayPixmap':
: undefined reference to `_XFlushGCCache'
XF86Rush.o(.text+0x978): In function `XF86RushStatusRegOffset':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0x9f7): In function `XF86RushStatusRegOffset':
: undefined reference to `_XReply'
XF86Rush.o(.text+0xa61): In function `XF86RushStatusRegOffset':
: undefined reference to `_XFlush'
XF86Rush.o(.text+0xab7): In function `XF86RushAT3DEnableRegs':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0xb44): In function `XF86RushAT3DEnableRegs':
: undefined reference to `XSync'
XF86Rush.o(.text+0xb60): In function `XF86RushAT3DEnableRegs':
: undefined reference to `_XFlush'
XF86Rush.o(.text+0xbb7): In function `XF86RushAT3DDisableRegs':
: undefined reference to `XMissingExtension'
XF86Rush.o(.text+0xc58): In function `XF86RushAT3DDisableRegs':
: undefined reference to `_XFlush'
collect2: ld returned 1 exit status
make[4]: *** [] Error 1
make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc/lib/Xxf86rush'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc'
make: *** [World] Error 2
!!! ERROR: x11-base/xorg-x11-6.7.0 failed.
!!! Function src_compile, Line 681, Exitcode 2

downgrading to the latest stable binutils on my arch (, makes xorg-x11 fail with the following error:

 * Building xorg-x11...
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognized option '--as-needed'
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status
make: [World] Error 1 (ignored)
Building Release 6.7.
I hope you checked the configuration parameters in ./config/cf
to see if you need to pass BOOTSTRAPCFLAGS.
Mon Apr 26 10:26:12 EDT 2004
cd ./config/imake && make  -f Makefile.ini BOOTSTRAPCFLAGS="" CC="gcc" clean
make[1]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc/config/imake'
rm -f ccimake imake.o imake
rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#*
rm -f -r Makefile.proto Makefile Makefile.dep bootstrap
rm -f imakemdep_cpp.h
make[1]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc/config/imake'
make  Makefile.boot
make[1]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc'
cd ./config/imake && make -w -f Makefile.ini BOOTSTRAPCFLAGS="" CC="gcc"
make[2]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc/config/imake'
gcc -o ccimake -DCROSSCOMPILEDIR=\"\"  -O -I../../include -I../../imports/x11/include/X11 ccimake.c
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognized option '--as-needed'
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status
make[2]: *** [ccimake] Error 1
make[2]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc/config/imake'
make[1]: *** [imake.proto] Error 2
make[1]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc'
make: *** [World] Error 2
!!! ERROR: x11-base/xorg-x11-6.7.0 failed.
!!! Function src_compile, Line 681, Exitcode 2

merging with binutils and gcc 3.4 allows xorg-x11 to compile without problem.

gcc 3.3.3-r3 gives the following version information: gcc (GCC) 3.3.3 20040412 (Gentoo Linux 3.3.3-r3, ssp-3.3-7, pie-8.5.3)
gcc 3.4 gives the following version information: gcc (GCC) 3.4.0 20040416 (prerelease)  (Gentoo Linux 3.4.0_pre20040416, pie-8.5.3)
Comment 1 solar (RETIRED) gentoo-dev 2004-04-26 12:51:21 UTC
emerge info

USE=hardend right?
If so then this is expected and invalid.
Comment 2 Travis Tilley (RETIRED) gentoo-dev 2004-04-26 15:12:53 UTC
no. look at the version output... i built them both without hardened in USE and didnt add it afterwards.

ayanami root # emerge info
Portage 2.0.50-r6 (default-amd64-2004.0, gcc-3.4.0, glibc-2.3.3_pre20040420-r0, 2.6.6-rc2-love1)
System uname: 2.6.6-rc2-love1 x86_64 4
Gentoo Base System version 1.4.9
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="amd64 ~amd64"
CFLAGS="-O2 -ftracer -pipe"
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/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -ftracer -pipe"
FEATURES="autoaddcvs buildpkg ccache cvs sandbox"
USE="X X509 aac acl acpi alsa amd64 apm arts avi berkdb bidi bonobo canna cap caps cddb cdr cjk crypt cscope dga directfb dnd dnsdb dv dvd dvdr encode escreen esd ethereal etwin evo faad fbcon fbdev ffmpeg fftw freetype fs gd gdbm geoip ggi gif glut gnome gnomedb gpm gstreamer gtk gtk2 gtkhtml icq idea ieee1394 imagemagick imap imlib jabber jack java jpeg kde kerberos ladcca lcms libg++ libgda libwww mad maildir md5sum mikmod motif mozilla moznocompose moznoirc moznomail mozp3p mozsvg mozxmlterm mpeg mpeg4 msn ncurses nls nogcj nvidia nviz offensive oggvorbis openal opengl oss pam pcap pcre pdflib perl pic png pnp prelude psyco pthreads python qt quicktime readline ruby sasl sdl serial skey slang slp snmp socks5 sox spell src ssl svg tcltk tcpd theora tiff timidity transcode transparent-proxy truetype type1 uml unicode usb v4l v4l2 videos wxwin wxwindows xchattext xfs xgetdefault xine xml2 xmms xv xvid yahoo zlib zvbi"
Comment 3 Torne Wuff 2004-05-02 11:11:00 UTC
I had this same issue on x86, but resolved it differently - below explains what I did to get it to work as I suspect this will help track down the bug.

1) Originally I had gcc-3.3.3-r3 and binutils- installed, and could successfully compile xorg.
2) I upgraded to binutils-
3) At some point, I recompiled gcc-3.3.3-r3 for unrelated reasons.
4) I tried to recompile xorg (to add USE=sdk) and got the same failure as the submitter (undefined references in XF86Rush).
5) I attempted to downgrade to binutils-, and ended up not being able to emerge anything whatsoever (with the same error about --as-needed as the submitter). Unfortunately I didn't save a package of 2.15, so my system was hosed.
6) I was suspicious that it worked before and didn't now, and thought that recompiling gcc may have been the issue. I looked on my other Gentoo box, which had also been upgraded to binutils-2.15-blahetc but had not had gcc recompiled since, and downgraded it to 2.14 - everything still worked, confirming that it's an interaction between binutils and gcc, not a plain binutils bug.
7) I packaged gcc from the working system and installed it on the broken one, leaving it with binutils 2.14 - everything now compiles, including xorg.

So, there are two problems:
1) xorg doesn't build properly using binutils 2.15 and gcc 3.3.3 (I've not tried using gcc 3.4). This is the one I'd kinda like fixed, as I'm pretty stumped - right now I'm just not upgrading to 2.15.
2) gcc breaks if you downgrade binutils from 2.15 to 2.14. I wasn't previously aware that gcc's behaviour depended on the installed binutils version, but clearly it does (as it attempts to invoke ld using different arguments when it was compiled in the presence of 2.15). This might not technically count as a bug, but it's awkward. =)
Comment 4 Brant Gurganus 2004-05-02 12:43:00 UTC
If you encounter the issue about GCC not working after binutils downgrade and don't have a pre-built package available.  I think I got my GCC to recompile by modifying the SPECS file to not have the --as-needed and --no-as-needed options.  I guess I'll see if that worked in about an hour when GCC finishes recompiling.
Comment 5 Brant Gurganus 2004-05-02 12:44:23 UTC
This is also not unique to amd64 as it happens on i386 as well.
Comment 6 BC 2004-05-02 13:07:26 UTC
I also had the same undefined reference problem with xf86rush on my x86 with gcc-3.3.3-r3 and binutils-  I downgraded binutils to the same version as in comment #3, but gcc didn't break.  In other words I was unable to reproduce problem 2 from comment #3.  Xorg is compiling fine for me now.  Its not finished, but its well past the point where I had been getting the xf86rush problem.
Comment 7 Torne Wuff 2004-05-02 15:06:09 UTC
Comment #6: Downgrading binutils breaks if your gcc was compiled after the new version of binutils was installed - if you have not compiled gcc since the upgrade, downgrading should not present any problems. Having looked in the specfile, it does indeed generate a slightly different set of linker options depending on whether binutils 2.14 or 2.15 was installed at compile time, and the options for 2.15 cause 2.14 to die.

I'm not sure whether the binutils downgrade thing should count as a bug; if it does, it should probably be noted in a seperate bug as it's unrelated to the issue of compiling xorg. The title/etc on this bug could do with being changed, too, as the problem is not amd64 specific; it occurs at least on x86 as well. 

As for why the latest binutils doesn't seem to be able to compile xorg, I have no idea. I don't think it's related to gcc versions as the original submitter suggested - I could before and now can again compile xorg using gcc-3.3.3-r3.
Comment 8 solar (RETIRED) gentoo-dev 2004-05-02 16:44:24 UTC
Can somebody please attach gcc specs when gcc is built with binutils-2.14 
and gcc specs when built binutils-2.15.

gcc -dumpspecs > gcc-$(gcc -dumpversion)$(ld -v | awk '{print $4"."$5}').$(gcc -dumpmachine).specs

And attach that here please.
Also could somebody local unmask gcc-3.3.3-r4 and see if problem persists.
Comment 9 Torne Wuff 2004-05-03 06:00:12 UTC
Created attachment 30591 [details]
gcc-3.3.3-r3 spec built with binutils-
Comment 10 Torne Wuff 2004-05-03 06:30:15 UTC
Created attachment 30594 [details]
gcc-3.3.3-r3 spec built with binutils-
Comment 11 Torne Wuff 2004-05-03 07:38:15 UTC
Using binutils-2.15 and gcc-3.3.3-r4 still fails to compile xorg with the same errors.
Comment 12 Martin Schlemmer (RETIRED) gentoo-dev 2004-05-03 10:55:40 UTC
Anybody could get binutils downgraded, and gcc recompiled?  If so, does that
fix xorg?
Comment 13 Torne Wuff 2004-05-03 11:57:52 UTC
Yes, downgrading binutils allows you to compile xorg successfully. You can only downgrade binutils if you have not recompiled gcc since you upgraded; otherwise, a downgrade will break your system (won't be able to compile anything) and you will have to use a binary package of gcc pre-upgrading (or hack the spec file) to fix it. If you want a quick workaround to get xorg to compile, then use quickpkg to back up a copy of binutils-2.15, downgrade it to, and then xorg should compile - if you find this breaks your system, then you can restore it to a working state by upgrading binutils using the binary package you saved (though this won't help you build xorg).
Comment 14 Martin Schlemmer (RETIRED) gentoo-dev 2004-05-03 12:05:02 UTC
So it really rather looks like a binutils-2.15 issue?
Comment 15 Torne Wuff 2004-05-03 12:11:56 UTC
Yup. Given that the original error is a failure in ld, and that reverting binutils fixes it, it doesn't look like gcc's fault at all. The original submitter thought he had fixed the problem by using gcc-3.4 but he states that he also downgraded to binutils-2.14 first.
Comment 16 Martin Schlemmer (RETIRED) gentoo-dev 2004-05-03 12:21:54 UTC
Maybe try dropping all the patches applied to 2.15, recompile and see
what happens?
Comment 17 PaX Team 2004-05-03 13:46:34 UTC
i don't think it's a toolchain problem per se, it's more like an incorrect makefile that doesn't list all dependencies when linking Xxf86rush. i've modified xorg-x11-6.7.0/work/xc/lib/Xxf86rush/Makefile around line 1048 to look like this:

cd .; $(CC) -o ./$@~ $(SHLIBLDFLAGS) -Wl,-soname,$$SONAME $(OBJS) $(EXTRASHAREDOBJS) $(REQUIREDLIBS) -L../Xext -L../X11 -lXext -lX11 -lc) || exit 1; \

and it links properly then (note the two extra libs and paths that i added). why the original worked with an older binutils is a mystery, an unresolved symbol is unresolved regardless of ld (or maybe -z defs wasn't used in that case?).
Comment 18 Donnie Berkholz (RETIRED) gentoo-dev 2004-05-03 13:54:32 UTC
'-z' wasn't in older xfree ebuilds, but it's always been in xorg-x11. See these lines in the X ebuilds:

    echo "#define SharedLibraryLoadFlags  -shared -Wl,-z,defs" \
        >> config/cf/host.def

Can you provide an Imakefile patch?
Comment 19 PaX Team 2004-05-03 14:00:55 UTC
i'm just being lazy, but adding this to the Imakefile in question should do the trick:

#ifdef SharedXxf86rushReqs
REQUIREDLIBS = SharedXxf86rushReqs
REQUIREDLIBS = -L../Xext -L../X11 -lXext -lX11

the original didn't have the #else part nor is SharedXxf86rushReqs defined anywhere else (at least xc/config has no sign of it, wonder where it should come from).
Comment 20 solar (RETIRED) gentoo-dev 2004-05-03 14:10:45 UTC
Comment 21 PaX Team 2004-05-03 14:51:31 UTC
ok, next bad guy: xorg-x11-6.7.0/work/xc/lib/xkbui/Makefile: needs -lm at around line 1030, or setting SharedxkbuiReqs somewhere in config/cf/ (there's a lnxLib.templ that already contains it, probably that's where -lm should go). in any case, asking upstream would be the best.
Comment 22 PaX Team 2004-05-03 15:11:51 UTC
xorg-x11-6.7.0/work/xc/lib/GL/mesa/src/OSmesa needs -lm as well.
Comment 23 PaX Team 2004-05-03 15:20:27 UTC
xorg-x11-6.7.0/work/xc/lib/GL/mesa/src/drv/i830 needs -lX11.
Comment 24 PaX Team 2004-05-03 15:27:01 UTC
xorg-x11-6.7.0/work/xc/lib/GL/mesa/src/drv/r200 needs -lX11 too.
Comment 25 PaX Team 2004-05-03 15:30:30 UTC
xorg-x11-6.7.0/work/xc/lib/GL/mesa/src/drv/tdfx needs -ldl .
Comment 26 PaX Team 2004-05-03 15:54:35 UTC
xorg-x11-6.7.0/work/xc/lib/GLw : this one is a more tricky animal, first it needs -lGL (e.g., you can add it to EXTENSIONLIB), but that's not enough, apparently GLwDAUtil.c (which is a symlink to ../../extras/ogl-sample/main/gfx/lib/glw/GLwDAUtil.c) has some non-gcc'ism to define weak symbols, that piece in the #ifdef USE_XM_STUBS should be replaced with:

__attribute__((weak)) _XmPrimitiveHighlightPixmapDefault;
__attribute__((weak)) _XmHighlightColorDefault;
__attribute__((weak)) _XmForegroundColorDefault;
__attribute__((weak)) _XmBackgroundColorDefault;
__attribute__((weak)) _XmStrings;
__attribute__((weak)) xmPrimitiveClassRec;
Comment 27 PaX Team 2004-05-03 16:01:31 UTC
xorg-x11-6.7.0/work/xc/lib/dpstk needs -lm .
Comment 28 PaX Team 2004-05-03 16:08:21 UTC
and that's where it stops for now, xorg-x11-6.7.0/work/xc/lib/XvMC/hw/i810 wants drm.h and it doesn't exist here... any ideas?
Comment 29 Donnie Berkholz (RETIRED) gentoo-dev 2004-05-03 16:48:14 UTC
donnie@supernova HEAD $ find ./ -name drm.h

It might get symlinked around some too.
Comment 30 Donnie Berkholz (RETIRED) gentoo-dev 2004-05-03 16:51:19 UTC
*** Bug 49913 has been marked as a duplicate of this bug. ***
Comment 31 solar (RETIRED) gentoo-dev 2004-05-03 20:16:57 UTC
So we can disable the --as-needed if we want to with a simple sed 
expression on gcc/*few_files but then a few arches that may desire it wont be able to benefit.

The related thread is at

I've updated the -* masked gcc-3.3.3-r4 to reflect this change and a few 
others. If we decide that we want to keep --as-needed for any arches then 
the sed expression in the ebuild will need to be updated to not disable it
for that arch.

Could somebody please test/confirm these changes
emerge rsync
unmask gcc-3.3.3-r4.ebuild (cvs rev 1.4)
emerge -pv gcc
emerge gcc
# post results here.
Comment 32 Austin Frank 2004-05-03 23:10:44 UTC
gcc-3.3.3-r4 built fine for me, but I still got the same errors when trying to emerge xorg-x11-6.7.0

gryphlet root # emerge info
Portage 2.0.50-r6 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040420-r0, 2.6.6-rc3-mm1)
System uname: 2.6.6-rc3-mm1 i686 Transmeta(tm) Crusoe(tm) Processor TM5800
Gentoo Base System version 1.4.10
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.3
CFLAGS="-march=i686 -O3 -pipe"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /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/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=i686 -O3 -pipe"
FEATURES="autoaddcvs ccache sandbox userpriv usersandbox"
USE="3dfx 3dnow X Xaw3d aac aalib acpi aim alsa apache2 avi berkdb cdr crypt cups curl dga directfb divx4linux dnd doc dv dvd emacs encode esd ethereal evms2 faad fam fbcon fbdev flac foomaticdb freetype fs gd gdbm gif gimpprint gphoto2 gpm gtk gtk2 hostap-nopci hostap-noplx imagemagick imlib innodb java javascript jikes jpeg lcms libcaca libg++ libwww lua mad mcal mikmod mmx mono motif moznoirc moznomail mozp3p mozsvg mpeg mysql ncurses odbc offensive oggvorbis opengl openssh opie oscar oss pam pcmcia pda pdflib perl pic plotutils png pnp ppds python qt quicktime radeon readline samba sasl sdk sdl slang slp speedo speex spell ssl svga tcltk tcpd tetex tiff truetype trusted type1 unicode usb v4l2 vim-with-x wavelan wmf wxwindows x86 xml xml2 xmms xosd xprint xv zlib"

gryphlet root # emerge -vp gcc
[ebuild   R   ] sys-devel/gcc-3.3.3-r4  +X -bootstrap -build -debug -f77 -gcj -hardened +java -multilib -nls -objc -static -uclibc  0 kB [1]

gryphlet root # emerge xorg-x11
[lots of undefined reference errors...]
collect2: ld returned 1 exit status
make[4]: *** [] Error 1
make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc/lib/Xxf86rush'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0/work/xc'
make: *** [World] Error 2

!!! ERROR: x11-base/xorg-x11-6.7.0 failed.
!!! Function src_compile, Line 681, Exitcode 2
!!! (no error message)
Comment 33 PaX Team 2004-05-04 05:56:33 UTC
ok, so xorg-x11-6.7.0/work/xc/lib/XvMC/hw/i810/Makefile needs -I$(XF86OSSRC)/shared/drm/kernel added to INCLUDES. then for linking it'll need -lXvMC and -lXv in REQUIREDLIBS.
Comment 34 solar (RETIRED) gentoo-dev 2004-05-04 08:36:12 UTC
Could make a note to this bug when you guys have made the changes to xorg. I'd like to test. -thanks
Comment 35 Brandon Hale (RETIRED) gentoo-dev 2004-05-04 09:01:37 UTC
I'm on the xfree alias, no need to get these twice.
Comment 36 PaX Team 2004-05-04 09:45:19 UTC
and finally a real killer i don't know how to fix easily: xorg-x11-6.7.0/work/xc/lib/font/bitmap/module references symbols that are resolved in the X server itself but it's not build at that point and i don't even know if it's possible to build the server first without having ready already. for now i removed -Wl,-z,defs from this makefile, but i think upstream should figure out what to do here, if -z defs is expected to work then this code has to be refactored.
Comment 37 PaX Team 2004-05-04 09:48:02 UTC
xorg-x11-6.7.0/work/xc/lib/font/Speedo/module has the same reference problem with the X server, i removed -Wl,-z,defs for now.
Comment 38 PaX Team 2004-05-04 09:52:17 UTC
and xorg-x11-6.7.0/work/xc/lib/font/Type1/module links to the X server too. as a sidenote i'd like to add that by removing -z defs we lose information, i.e., there could be unresolved symbols not resolved by the X server itself, we can find them when the first problem is solved (code refactoring or whatever), or someone greps through the codebase for every single unresolved symbol...
Comment 39 PaX Team 2004-05-04 09:58:21 UTC
xorg-x11-6.7.0/work/xc/lib/font/FreeType/module needs -lm and something else that provides FontEncRecode and others plus the X server, so no -z defs for now.
Comment 40 PaX Team 2004-05-04 10:01:12 UTC
xorg-x11-6.7.0/work/xc/lib/font/X-TrueType/module links to the X server and something else (FontDefaultFormat and the like), no -z defs for now.
Comment 41 PaX Team 2004-05-04 10:05:49 UTC
xorg-x11-6.7.0/work/xc/lib/font/X-TrueType/ISO8859.1/module needs -lxtt -L../../module .
Comment 42 PaX Team 2004-05-04 10:24:19 UTC
looks like pretty much everyone in xorg-x11-6.7.0/work/xc/lib/font/X-TrueType/*/module needs -lxtt -L../../module, some even the X server (like JISX020*).
Comment 43 PaX Team 2004-05-04 10:33:42 UTC
xorg-x11-6.7.0/work/xc/lib/font needs -lm and others i can't track down. looks like some dependency on freetype2 (FT_Get_Sfnt_Name and similar) but then it's not built at all.
Comment 44 solar (RETIRED) gentoo-dev 2004-05-04 10:36:07 UTC
a few [ -z/-n "`use blah`" ] conditions were not being satisfied in gcc-3.3.3-r4 
They have been corrected in (cvs rev 1.6)
Comment 45 PaX Team 2004-05-04 11:04:40 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/Xext/extmod needs the X server, no -z defs for now.
Comment 46 PaX Team 2004-05-04 11:12:16 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/GL/glx needs -L../../../../lib/GL/GL/ -lGL and then the X server as well, so no -z defs.
Comment 47 PaX Team 2004-05-04 11:21:41 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/GL/dri needs -L../../../../lib/XvMC/hw/i810 -lI810XvMC (specific to my hw, no idea what the proper approach is here) and the X server, so no -z defs...
Comment 48 PaX Team 2004-05-04 11:36:52 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/GL/mesa/GLcore needs -L../../../dix -ldix and the X server, so no -z defs.
Comment 49 PaX Team 2004-05-04 11:41:29 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/GL needs -L../../../lib/GL/GL -lGL and the X server, no -z defs...
Comment 50 PaX Team 2004-05-04 11:43:46 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/dbe/module needs the X server, no -z defs.
Comment 51 PaX Team 2004-05-04 11:44:57 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/record/module needs the X server, no -z defs.
Comment 52 PaX Team 2004-05-04 11:46:45 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/XTrap/module needs the X server, no -z defs.
Comment 53 PaX Team 2004-05-04 11:50:47 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/mfb also needs the X server, so -z defs can't be used.
Comment 54 PaX Team 2004-05-04 12:19:55 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/fb, xorg-x11-6.7.0/work/xc/programs/Xserver/afb, xorg-x11-6.7.0/work/xc/programs/Xserver/cfb*  all need the X server and hence -z defs can't be used.
Comment 55 PaX Team 2004-05-04 12:22:42 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/miext/shadow needs -lfb -L../../fb and the X server, so -z defs can't be used.
Comment 56 PaX Team 2004-05-04 12:24:38 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/miext/layer needs the X server, so -z defs cannot be used.
Comment 57 PaX Team 2004-05-04 12:35:56 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/xf1bpp need the X server, -z defs cannot be used.
Comment 58 PaX Team 2004-05-04 12:37:13 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/xf4bpp needs -L../xf1bpp -lxf1bpp and the X server, so -z defs can't be used.
Comment 59 PaX Team 2004-05-04 12:42:45 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/xf8_32bpp needs -L../../../cfb32 -lcfb32 -L../../../cfb -lcfb and the X server, so -z defs can't be used.
Comment 60 PaX Team 2004-05-04 12:49:53 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/xf8_16bpp needs -L../../../cfb16 -lcfb16 -L../../../cfb -lcfb and the X server, so -z defs can't be used.
Comment 61 PaX Team 2004-05-04 12:52:22 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/xf24_32bpp needs -L../../../cfb32 -lcfb32 -L../../../cfb24 -lcfb24 and the X server so -z defs cannot be used.
Comment 62 PaX Team 2004-05-04 12:58:00 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/shadowfb needs the X server so -z defs cannot be used.
Comment 63 PaX Team 2004-05-04 13:09:04 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/drivers/mga needs -L../../os-support/linux/drm -ldrm -L../../../../GL/dri -ldri -L../../xaa -lxaa -L../../vbe -lvbe -L../../vgahw -lvgahw -L../../xf8_32bpp -lxf8_32bpp (and probably more, i got tired of tracking it more ;-) whereas
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/vbe and xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/vgahw have to be built before drivers... (and of course no -z defs in any case).
Comment 64 PaX Team 2004-05-04 13:25:14 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/drivers/glint needs -L../../xaa -lxaa -L../../../../fb -lfb -L../../../../GL/dri -ldri -L../../os-support/linux/drm -ldrm -L../../ramdac -lramdac -L../../vbe -lvbe -L../../fbdevhw -lfbdevhw whereas xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/ramdac and xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/fbdevhw need to be built beforehand (and all of these needs the X server, so -z defs can't be used).
Comment 65 PaX Team 2004-05-04 13:29:03 UTC
ok, this is gonna be long, i'll take a shortcut and just build the drivers without -z defs, someone else will have to figure out the precise dependencies... there're 'small' issues like the 'nv' driver needing RivaAvailableOptions but not compiling riva_driver.c in the same dir... oops. so it'll take a while to sort this out.
Comment 66 PaX Team 2004-05-04 14:33:53 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/rac needs the X server, so -z defs won't work.
Comment 67 PaX Team 2004-05-04 14:40:21 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/ddc, xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/input/* need the X server, blablabla.
Comment 68 PaX Team 2004-05-04 14:54:15 UTC
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/int10 and xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/scanpci/module need the X server... and that looks like the last pieces, after this the X server links nicely.
Comment 69 PaX Team 2004-05-05 02:43:40 UTC
so, as a final update, i've missed a few dependencies in, and some more, once fixed everything works fine with the dlloader when i add a few paths to /etc/env.d/10xorg (LDPATH=/usr/X11R6/lib:/usr/X11R6/lib/modules:/usr/X11R6/lib/modules/linux:/usr/X11R6/lib/modules/extensions), no need to put all dependencies into xorg.conf by hand. i also had RELRO active however USE=pie didn't quite work out, maybe because i eventually compiled X manually not through the ebuild. anyway, i think we're fairly close to have a working X server with dlloader, these dependencies are easy to fix by hand but upstream should know how to do it properly (i.e., where to change the imakefiles, add new defines if needed, etc). for text relocations we'll need my older X patches plus some updates, let's look at that once we can automatically build this server with dlloader.
Comment 70 Travis Tilley (RETIRED) gentoo-dev 2004-05-05 05:00:52 UTC
i'd like to note that this problem needs to be fixed for normal users who dont use the dlloader, and archs (like mine) where the dlloader isn't even a possibility far off in the distance yet.
Comment 71 Brandon Hale (RETIRED) gentoo-dev 2004-05-05 08:03:28 UTC
Upstream report at
Comment 72 Donnie Berkholz (RETIRED) gentoo-dev 2004-05-05 08:58:52 UTC
I've removed our custom SharedLibraryLoadFlags defs for now, which should work around the issue until it's fixed.
Comment 73 Donnie Berkholz (RETIRED) gentoo-dev 2004-05-06 21:43:46 UTC
Bug #49363 is around for the downgrading binutils breaking the system issue.
Comment 74 SpanKY gentoo-dev 2005-01-11 16:14:40 UTC
i havent followed this bug at all but binutils- is now x86 stable ...
Comment 75 Donnie Berkholz (RETIRED) gentoo-dev 2005-01-11 16:31:15 UTC
The basic problem was that binutils 2.15 handled -z differently, so X builds died when they were built with it because not all the symbols between modules and server are resolvable.

The fix was to stop building X with -z. I don't foresee a better fix, so this bug could probably be closed.
Comment 76 Donnie Berkholz (RETIRED) gentoo-dev 2005-01-27 00:22:54 UTC
This is a bug with X's server-module setup.
Comment 77 Donnie Berkholz (RETIRED) gentoo-dev 2005-02-05 01:06:20 UTC
Not our bug. Please file one at if you're interested in pursuing this further, and post the URL here.

Comment 78 Adam Jackson 2005-02-05 09:03:21 UTC
already upstreamed:

though my analysis there is incomplete.