| Summary: | XFree fails on startup with unresolved gnu_dev_makedev from glibc | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ryan Breen <ryan> |
| Component: | [OLD] Core system | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | ajax, desrt, kllba |
| Priority: | High | Keywords: | Inclusion |
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
XFree86.0.log showing error
patch of goodness |
||
|
Description
Ryan Breen
2004-02-17 15:32:28 UTC
Created attachment 25805 [details]
XFree86.0.log showing error
As further data points, I tried an emerge -e world and an update to the new stock 2.6.3 kernel (on the hope that it was really my i830.o that was triggering the problem). Behavior has not changed. I was able to fix this by changing my CFLAGs and rebuilding everything from gcc through xfree --
New:
CFLAGS="-march=pentium3 -O3 -pipe"
CXXFLAGS="${CFLAGS}"
Old:
CFLAGS="-march=pentium3 -pipe -fomit-frame-pointer"
#CXXFLAGS="${CFLAGS}"
Because I changed my cflags and properly set the cxxflags at the same time, I'm not sure which change fixed things. I guess it's most likely that there was weirdness because the C++ apps were compiled differently than the C libraries, so chalk this one up to stupid user misconfiguration ;-)
Let us know if the problem crops up again. I too have this problem xfree-4.3.0-r3 was fine then all of a sudden with r4 this happened and again with r5. To solve this I've kept a working libdrm.a (which is where I've located the bug to. replaceing the compiled libdrm.a with the backed up one starts X. Why would this be happening? I've got the same problem! I emerged latest glibc and xfree-4.3.0-r5 but it returns always the same error:
Symbol gnu_dev_makedev from module /usr/X11R6/lib/modules/linux/libdrm.a is unresolved!
Myflags:
FLAGS="-march=athlon-xp"
CXXFLAGS="${CFLAGS}"
My gcc -v:
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs
Configured with: /var/tmp/portage/gcc-3.3.3/work/gcc-3.3.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,f77,objc,java --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-interpreter --enable-java-awt=xlib --with-x --disable-multilib
Thread model: posix
gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)
I think that the bug still exists, and isn't resolved
Josef Grunig
Which version of linux-headers are you all on? linux-headers == 2.4.21 kernel == 2.6.3 kernel = 2.6.1-r1 linux-headers= 2.4.19-r1 Mine is the same too: kernel=2.6.3 headers=2.4.21
Fixed by changing CFLAGS and emerging same version of xfree.
failed: CFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer"
failed: CFLAGS="-march=athlon -O3 -pipe"
works: CFLAGS="-march=athlon -O3 -fomit-frame-pointer"
/etc/make.conf:
#CXXFLAGS="${CFLAGS}"
xfree-4.3.0-r5
headers == 2.6.4-rc2
kernel == 2.6.4-rc2
That's about the weirdest thing I've ever seen. Looks like the -pipe flag broke it, potentially in combination with -O3. Been digging around and all talk in comments #3 and comment #11 is completely invalid conjecture on this bug. They provide some solution that lies outside of XFree. IRT #3: CFLAGS="-march=pentium3 -O3 -pipe" implies that -fomit-frame-pointer is used (see the gcc manual if you dont believe me, unless you're using VAX this is on from -O to -O3). Futher more setting CXXFLAGS will have limited to no effect on the Xfree server as it is all C code. IRT #11: CFLAGS="-pipe" (or including -pipe) does not effect the actual usage of compiled binaries. All -pipe allows is piped gcc communication during the compilation. Provided you use a pipe assembler then this is fine (ie the compile would bork otherwise). Could everyone that has had this problem or is having this problem please run and post the following. 1) nm /usr/X11R6/lib/modules/linux/libdrm.a |grep makedev 2) grep -R makedev /usr/X11R6/* I've recently noticed my environment for root has changed. It's likely that one or more of the tests I did (#11) were using CFLAGS="-g3 -Wall"! I'm currently recompiling xfree to recreate the bug. (These are from the working xfree setup. No missing makedev symbol.) $ nm /usr/X11R6/lib/modules/linux/libdrm.a |grep makedev # grep -R makedev /usr/X11R6/* (no results for either) So how did it go James? Anyone with this problem been using binary drivers? Do they provide an alternate libdrm.a with this symbol? An su to root preserves my development env "CFLAGS=-g3 -Wall". The
emerge with /etc/make.conf CFLAGS is overriden by my environment. (Is
that proper?) -g3 -Wall seems to cause the unresolved symbol:
# nm /usr/X11R6/lib/modules/linux/libdrm.a |grep makedev
U gnu_dev_makedev
# grep -R makedev /usr/X11R6/lib/
Binary file /usr/X11R6/lib/modules/dri/radeon_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/tdfx_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/i810_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/r128_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/i830_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/mga_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/r200_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/ffb_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/gamma_dri.so matches
Binary file /usr/X11R6/lib/modules/linux/libdrm.a matches
Binary file /usr/X11R6/lib/libI810XvMC.a matches
Both the "radeon" driver, and "fglrx" have the same error result.
X will start up when I turn fglrx's dri off:
Option "no_dri" "yes"
or (with 'radeon' driver), comment out:
Load "dri"
$ ls -al /usr/X11R6/lib/modules/linux
total 110
drwxr-xr-x 2 root root 168 Mar 27 04:14 .
drwxr-xr-x 9 root root 1016 Mar 26 16:22 ..
-r--r--r-- 1 root root 44112 Mar 26 16:21 libdrm.a
-r--r--r-- 1 root root 13224 Mar 26 16:21 libfbdevhw.a
-rw-r--r-- 1 root root 11178 Mar 21 18:25 libfglrxdrm.a
-r--r--r-- 1 root root 35040 Mar 26 16:21 libint10.a
$ nm /usr/X11R6/lib/modules/linux/libfglrxdrm.a |grep makedev
$
I moved libfglrxdrm.a to my home dir, and the 'radeon' driver behaved
the same (unresolved gnu_dev_makedev).
Anything else I should try?
one more thing:
$ nm /usr/X11R6/lib/modules/dri/radeon_dri.so |grep makedev
U gnu_dev_makedev@@GLIBC_2.3.3
> An su to root preserves my development env "CFLAGS=-g3 -Wall". The
> emerge with /etc/make.conf CFLAGS is overriden by my environment. (Is
> that proper?) -g3 -Wall seems to cause the unresolved symbol:
Yes. Environment should override.
# nm /usr/X11R6/lib/modules/linux/libdrm.a |grep makedev
U gnu_dev_makedev
# grep -R makedev /usr/X11R6/*
Binary file /usr/X11R6/lib/libI810XvMC.so matches
Binary file /usr/X11R6/lib/modules/dri/sis_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/radeon_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/tdfx_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/i810_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/r128_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/i830_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/mga_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/r200_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/gamma_dri.so matches
Binary file /usr/X11R6/lib/modules/linux/libdrm.a matches
Binary file /usr/X11R6/lib/libI810XvMC.so.1 matches
Binary file /usr/X11R6/lib/libI810XvMC.a matches
Binary file /usr/X11R6/lib/libI810XvMC.so.1.0 matches
If I'm running X with the Via drivers and I disable DRI in XF86Config X starts fine.
If I enable dri it dies with the same error everyone else is getting.
If I start X with the VESA drivers then I can enable DRI although X crashes when I run glxinfo.
I will check my CFLAGS and try emerging again I guess.
Oh I'm running Xfree 4.4.0 from the Unichrome-r3 ebuild and my kernel is 2.4.25-epia-r1.
Following https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119984 also. Same here:
Error:
(WW) RADEON(0): Failed to set up write-combining range (0xd0000000,0x2000000)
Symbol gnu_dev_makedev from module /usr/X11R6/lib/modules/linux/libdrm.a is unresolved!
Installed:
[ebuild R ] x11-base/xfree-4.3.0-r5
[ebuild R ] sys-libs/glibc-2.3.2-r9
[ebuild R ] sys-kernel/linux-headers-2.4.21-r1
Requested:
bash-2.05b# nm /usr/X11R6/lib/modules/linux/libdrm.a |grep makedev
U gnu_dev_makedev
bash-2.05b# grep -R makedev /usr/X11R6/*
Binary file /usr/X11R6/lib/modules/dri/radeon_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/tdfx_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/i810_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/r128_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/i830_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/mga_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/r200_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/ffb_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/gamma_dri.so matches
Binary file /usr/X11R6/lib/modules/linux/libdrm.a matches
grep: /usr/X11R6/lib/modules/extensions/libglx.so: No such file or directory
Binary file /usr/X11R6/lib/libI810XvMC.a matches
/etc/make.conf
VIDEO_CARDS="radeon"
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe"
CXXFLAGS="${CFLAGS}"
Comment out from /etc/X11/XF86Config-4 #Load "dri" and X works, but no DRI obviously.
I'd love a solution.
Go figure. Works now. Drop out of X emerge unmerge xfree emerge unmerge xfree-drm (if it exists) emerge xfree Enable dri in XF86Config-4 -> Works fine now. Same unresolved symbol problem as everyone else here, but I'm running xorg.
Potentially relevant packages:
[ebuild R ] sys-kernel/development-sources-2.6.6
[ebuild R ] sys-kernel/linux-headers-2.4.21-r1
[ebuild R ] x11-base/xorg-x11-6.7.0-r1
[ebuild N ] x11-base/xfree-drm-4.3.0-r7 +gatos 419 kB
% nm /usr/X11R6/lib/modules/linux/libdrm.a |grep makedev
U gnu_dev_makedev
% grep -R makedev /usr/X11R6/*
grep: /usr/X11R6/bin/X: Permission denied
grep: /usr/X11R6/bin/Xorg: Permission denied
grep: /usr/X11R6/bin/xterm: Permission denied
Binary file /usr/X11R6/lib/libI810XvMC.so.1.0 matches
Binary file /usr/X11R6/lib/libI810XvMC.so.1 matches
Binary file /usr/X11R6/lib/libI810XvMC.a matches
Binary file /usr/X11R6/lib/modules/dri/i830_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/tdfx_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/r128_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/radeon_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/i810_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/mga_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/sis_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/r200_dri.so matches
Binary file /usr/X11R6/lib/modules/dri/gamma_dri.so matches
Binary file /usr/X11R6/lib/modules/linux/libdrm.a matches
Binary file /usr/X11R6/lib/libI810XvMC.so matches
grep: /usr/X11R6/man/de/man1/gsdj500.1.gz: No such file or directory
grep: /usr/X11R6/man/de/man1/gsbj.1.gz: No such file or directory
grep: /usr/X11R6/man/de/man1/gslj.1.gz: No such file or directory
grep: /usr/X11R6/man/de/man1/gsdj.1.gz: No such file or directory
It -was- working correctly as recently as yesterday; since then, I have changed my CFLAGS and USE flags. I have not upgraded any packages in the meanwhile, although I have rebuilt several.
Firstly, I put -ipv6 and recompiled everything that used that USE flag; I believe it was still working at that point.
Later, I changed my CFLAGS from CFLAGS="-O3 -march=athlon-xp -pipe" to
CFLAGS="-ggdb3 -march=athlon-xp -pipe". I then did an emerge -e pam to rebuild most of the core system [that rebuilt both glibc and xorg-x11; I didn't want to rebuild KDE, etc.]
Finally, I put debug in my USE variables, and recompiled gcc and glibc, then rebooted. Now, startx doesn't work unless I disable dri.
Even after an emerge -e xorg-x11, this problem persists.
Here is my current setup:
% emerge info
Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.6)
=================================================================
System uname: 2.6.6 i686 AMD Athlon(TM) XP 2500+
Gentoo Base System version 1.4.16
distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-ggdb3 -march=athlon-xp -pipe"
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/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="-ggdb3 -march=athlon-xp -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs buildpkg ccache distcc nostrip sandbox userpriv usersandbox"
GENTOO_MIRRORS="http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow X acl alsa apm arts audiofile avi berkdb bidi canna cdr cjk composite crypt cscope cups debug directfb doc dvd dvdr emacs encode faad flac foomaticdb freewnn gatos gd gdbm gimpprint gphoto2 gpm gtk gtk2 guile imlib java javascript jikes jpeg junit kde libg++ libwww mad mikmod mmx mng mpeg mysql ncurses nls oggvorbis opengl pam pdflib perl pic png ppds python qt quicktime readline ruby scanner sdl slang socks5 softmmu spell sse ssl tcltk tcpd tetex theora tiff truetype usb video_cards_radeon wmf x86 xinerama xml2 xmms xv zlib"
Try dropping pie from USE, rebuilding glibc, then rebuilding xorg-x11. Sorry, I did mean pic, not pie. I rebuilt, with the command: USE="-pic" emerge --oneshot glibc xorg-x11 Same error as before. :/ Here's an interesting twist.... http://forums.viaarena.com/messageview.cfm?catid=28&threadid=54481 I -can- load dri in the current config, iff I don't load glx. The problem only occurs if one tries to load -both-. Btw, I have never used the ati binary drivers. The missing symbol seems to be a bit of a red herring. I made 3 logs, one with dri disabled, one with glx disabled, and one with both enabled; the first two both successfully launch, while the last doesn't. % grep unres val* val_bad.log:Symbol gnu_dev_makedev from module /usr/X11R6/lib/modules/linux/libdrm.a is unresolved! val_bad.log: *** If unresolved symbols were reported above, they might not val_nodri.log:Symbol drmGetClient from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! val_noglx.log:Symbol gnu_dev_makedev from module /usr/X11R6/lib/modules/linux/libdrm.a is unresolved! val_noglx.log:Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved! val_noglx.log:Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved! Here's where gdb from a remote machine ssh'd in gets me. # gdb X (gdb) set args :1 -nolisten tcp -br -deferglyphs 16 (gdb) display /i $pc (gdb) run Starting program: /usr/X11R6/bin/X :1 -nolisten tcp -br -deferglyphs 16 (the same X11 startup messages as usual, until...) Program received signal SIGILL, Illegal instruction. 0x0832c97c in ?? () 1: x/i $pc 0x832c97c: (bad) (gdb) bt #0 0x0832c97c in ?? () #1 0x0832c97f in ?? () #2 0x000000e2 in ?? () #3 0x00000000 in ?? () #4 0xbffff498 in ?? () #5 0x40180560 in __libc_tsd_MALLOC_data () from /lib/libc.so.6 #6 0x4017fb88 in __elf_set___libc_thread_subfreeres_element___rpc_thread_destroy__ () from /lib/libc.so.6 #7 0x083a6c58 in ?? () #8 0x40180560 in __libc_tsd_MALLOC_data () from /lib/libc.so.6 #9 0xbffff498 in ?? () #10 0x400d5a0d in free () from /lib/libc.so.6 #11 0x0832ca15 in ?? () #12 0x00000000 in ?? () #13 0x00000001 in ?? () #14 0xbffff4f8 in ?? () #15 0x08090aee in xf86LoaderCheckSymbol () #16 0x083286e4 in ?? () #17 0x082f3f70 in ?? () #18 0xbffff7d4 in ?? () #19 0xbffff528 in ?? () #20 0x0810b62c in Xalloc () (... etc ... - despite compiling with -ggdb3 and setting debug in USE, I still haven't gotten /lib/libc.so.6 to have debugging symbols, unfortunately.) The -real- problem is the signal 4, illegal instruction; unfortunately, I still have no idea exactly why the combination of loading dri and glx triggers it. I have a fixer for this bug. It is caused by /usr/include/sys/sysmacros.h (which comes as part of glibc, of course) xf86drm.c uses makedev() from this file expecting it to be a macro. It is not a macro in glibc 3.3.3, however. It's defined as an external function gnu_dev_makedev. This causes a dependancy on this function by the object file. When the file is loaded into the xserver, gnu_dev_makedev isn't available in the namespace and so it fails. xf86drm.c defines its own version of makedev() for use in the event that the system headers don't have one. I fixed the problem by a well-placed '#undef makedev' to let the macro in xf86drm.c take effect. The attached patch isn't a great solution. This is something that will need to be fixed upstream in all the X servers (or better yet, in glibc.) It works for now for me, though. As always, ymmv (but I hope not.) Created attachment 35453 [details, diff]
patch of goodness
Fix for the problem.
cyfred, can you please look at this ASAP and suggest a better patch if necessary? I'd like to get a fix for this into -r2 if possible, now that we've got something to work from. BTW, I'd like to get -r2 in the tree in about 24 hours. Patch solved my gnu_dev_makedev unresolved symbol issue. cyfred: reping gcc's inline keyword is worthless. i'll bring this up on dri-devel@, should be fixed in the next Xorg release. reported upstream as: https://freedesktop.org/bugzilla/show_bug.cgi?id=979 fixed in upstream. I'll see if I can toss a patch into 6.7.0 sometime. If not, advice to any users encountering this is to test the next 6.8.0 ebuild that hits the tree. 6.7.99.1 won't do the trick -- looks as if it was before this commit. Seemant, if you feel like adding this to 6.7.99.1, go ahead. is is just xf86drm.c? yep, just xf86drm.c there'll probably be a 6.7.99.2 at least before we release. Should be fixed in 6.8 |
