when I attempt to merge xorg-x11 with binutils 2.15.90.0.3-r1 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 libXxf86rush.so.1.0~ + cd . + gcc -o ./libXxf86rush.so.1.0~ -shared -Wl,-z,defs -Wl,-soname,libXxf86rush.so.1 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]: *** [libXxf86rush.so.1.0] 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 (2.14.90.0.8-r1), 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' making imake with BOOTSTRAPCFLAGS= and CROSSCOMPILEFLAGS=-DCROSSCOMPILEDIR="" in 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 2.14.90.0.8-r1 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)
emerge info USE=hardend right? If so then this is expected and invalid.
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" AUTOCLEAN="yes" CFLAGS="-O2 -ftracer -pipe" CHOST="x86_64-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/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -ftracer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache cvs sandbox" 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="" SYNC="rsync://localhost/portage" 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"
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-2.14.90.0.8-r1 installed, and could successfully compile xorg. 2) I upgraded to binutils-2.15.90.0.3-r1. 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-2.14.90.0.8-r1, 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. =)
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.
This is also not unique to amd64 as it happens on i386 as well.
I also had the same undefined reference problem with xf86rush on my x86 with gcc-3.3.3-r3 and binutils-2.14.90.0.8-r1. 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 #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.
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.
Created attachment 30591 [details] gcc-3.3.3-r3 spec built with binutils-2.14.90.0.8-r1
Created attachment 30594 [details] gcc-3.3.3-r3 spec built with binutils-2.15.90.0.3-r1
Using binutils-2.15 and gcc-3.3.3-r4 still fails to compile xorg with the same errors.
Anybody could get binutils downgraded, and gcc recompiled? If so, does that fix xorg?
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 2.14.90.0.8-r1, 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).
So it really rather looks like a binutils-2.15 issue?
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.
Maybe try dropping all the patches applied to 2.15, recompile and see what happens?
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?).
'-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?
i'm just being lazy, but adding this to the Imakefile in question should do the trick: #ifdef SharedXxf86rushReqs REQUIREDLIBS = SharedXxf86rushReqs #else REQUIREDLIBS = -L../Xext -L../X11 -lXext -lX11 #endif 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).
http://gcc.gnu.org/ml/gcc-bugs/2004-04/msg01420.html
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.
xorg-x11-6.7.0/work/xc/lib/GL/mesa/src/OSmesa needs -lm as well.
xorg-x11-6.7.0/work/xc/lib/GL/mesa/src/drv/i830 needs -lX11.
xorg-x11-6.7.0/work/xc/lib/GL/mesa/src/drv/r200 needs -lX11 too.
xorg-x11-6.7.0/work/xc/lib/GL/mesa/src/drv/tdfx needs -ldl .
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: #ifdef USE_XM_STUBS __attribute__((weak)) _XmPrimitiveHighlightPixmapDefault; __attribute__((weak)) _XmHighlightColorDefault; __attribute__((weak)) _XmForegroundColorDefault; __attribute__((weak)) _XmBackgroundColorDefault; __attribute__((weak)) _XmStrings; __attribute__((weak)) xmPrimitiveClassRec; #endif
xorg-x11-6.7.0/work/xc/lib/dpstk needs -lm .
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?
donnie@supernova HEAD $ find ./ -name drm.h ./xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/drm.h It might get symlinked around some too.
*** Bug 49913 has been marked as a duplicate of this bug. ***
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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14992 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.
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 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=i686 -O3 -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/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" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox userpriv usersandbox" GENTOO_MIRRORS="ftp://mirror.cc.columbia.edu/pub/linux/gentoo/distro" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" 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]: *** [libXxf86rush.so.1.0] 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)
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.
Donnie, Could make a note to this bug when you guys have made the changes to xorg. I'd like to test. -thanks
I'm on the xfree alias, no need to get these twice.
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 libbitmap.so 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.
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.
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...
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.
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.
xorg-x11-6.7.0/work/xc/lib/font/X-TrueType/ISO8859.1/module needs -lxtt -L../../module .
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*).
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.
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)
xorg-x11-6.7.0/work/xc/programs/Xserver/Xext/extmod needs the X server, no -z defs for now.
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.
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...
xorg-x11-6.7.0/work/xc/programs/Xserver/GL/mesa/GLcore needs -L../../../dix -ldix and the X server, so no -z defs.
xorg-x11-6.7.0/work/xc/programs/Xserver/GL needs -L../../../lib/GL/GL -lGL and the X server, no -z defs...
xorg-x11-6.7.0/work/xc/programs/Xserver/dbe/module needs the X server, no -z defs.
xorg-x11-6.7.0/work/xc/programs/Xserver/record/module needs the X server, no -z defs.
xorg-x11-6.7.0/work/xc/programs/Xserver/XTrap/module needs the X server, no -z defs.
xorg-x11-6.7.0/work/xc/programs/Xserver/mfb also needs the X server, so -z defs can't be used.
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.
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.
xorg-x11-6.7.0/work/xc/programs/Xserver/miext/layer needs the X server, so -z defs cannot be used.
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/os-support/linux/drm, xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/os-support/linux/int10, xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/i2c, xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/xaa, xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/xf1bpp need the X server, -z defs cannot be used.
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.
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.
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.
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.
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/shadowfb needs the X server so -z defs cannot be used.
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).
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).
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.
xorg-x11-6.7.0/work/xc/programs/Xserver/hw/xfree86/rac needs the X server, so -z defs won't work.
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.
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.
so, as a final update, i've missed a few dependencies in libdrm.so, libdri.so 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.
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.
Upstream report at http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=600
I've removed our custom SharedLibraryLoadFlags defs for now, which should work around the issue until it's fixed.
Bug #49363 is around for the downgrading binutils breaking the system issue.
i havent followed this bug at all but binutils-2.15.92.0.2-r1 is now x86 stable ...
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.
This is a bug with X's server-module setup.
Not our bug. Please file one at bugs.freedesktop.org if you're interested in pursuing this further, and post the URL here. Thanks.
already upstreamed: https://bugs.freedesktop.org/show_bug.cgi?id=600 though my analysis there is incomplete.
