After emerge the latest kernel headers (linux26-headers-2.6.8.1-r1) and then recompiling glibc, the following error is obtained on rebooting and attempting to start X : 'X relocation error:x symbol --guard, version GLIBC2.3.2 not defined in file libc.so.6 with time reference'
I have the same problem here. My "emerge info" is below. I think this should be changed from Major to Critical since it prevents X from working. Portage 2.0.51-r3 (default-linux/x86/2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9 i686) ================================================================= System uname: 2.6.9 i686 AMD Duron(tm) Gentoo Base System version 1.4.16 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1-r1,sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-Os -march=athlon-xp -mfpmath=sse -msse -mmmx -m3dnow -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /lib/modules /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/webapps/tikiwiki/1.8.3/htdocs/lib/ /var/qmail/alias /var/qmail/control /var/www/www.east308.net/htdocs/tikiwiki/templates" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=athlon-xp -mfpmath=sse -msse -mmmx -m3dnow -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://mir.zyrianes.net/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://212.219.56.146/sites/www.ibiblio.org/gentoo/ http://212.219.56.131/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/usr/portage/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowex X aac aalib acpi alsa apache2 ared aredmem audiofile avi bitmap-fonts canna caps cjk crypt dga divx4linux djbfft dv dvd dvdr dvdread emacs encode flac gd ggi gif gtk2 imagemagick imap imlib ipv6 irda jack jack-tmpfs jpeg libg++ lirc live lzo mad maildir matroska matrox memlimit mikmod mime mmx mmx2 moznocompose moznoirc moznomail moznoxft mozplaintext mp3 mpeg mysql ncurses network nls nojoystick nptl offensive oggvorbis opengl oss pam pcre pdflib perl pic png posix quicktime readline rtc sdl session sockets sse ssl svga tcpd tga theora transcode truetype userlocales v4l v4l2 x86 xfs xv xvid zlib video_cards_matrox"
OK, I've found how to fix it on my computer: run prelink again.
I do not use prelink and have the same problem. I assume prelinking is not the general solution to this problem
This is happening with much more than just X. On my machine at work the following, at least, got broken. kwrite (kdebase) libkateutils.so.0 kmail (kdebase) due to libgpgme-blah (gpgme) xoowriter (ximian-openoffice) ssh(d) KMail, X, and ssh(d) were fixed by re-emerging gpgme, xorg-x11, and openssh respecively. I have another machine which can't even compile glibc with the new headers. gcc -nostdlib -nostartfiles -o /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/iconvconfig -Wl,-dynamic-linker=/lib/ld-linux.so.2 -Wl,-O1 -Wl,-z,combreloc -Wl,-z,relro /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/csu/crt1.o /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/csu/crti.o `gcc --print-file-name=crtbegin.o` /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/iconvconfig.o /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/strtab.o /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/xmalloc.o /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/hash-string.o -Wl,-rpath-link=/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build:/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/math:/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/elf:/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/dlfcn:/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/nss:/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/nis:/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/rt:/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/resolv:/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/crypt:/var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/nptl /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/libc.so.6 /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/libc_nonshared.a -lgcc -lgcc_eh `gcc --print-file-name=crtend.o` /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/csu/crtn.o /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/iconvconfig.o(.text+0x1b): In function `main': : undefined reference to `__guard' /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/iconvconfig.o(.text+0x124): In function `main': : undefined reference to `__guard' /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/iconvconfig.o(.text+0x142): In function `main': : undefined reference to `__stack_smash_handler' /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/iconvconfig.o(.text+0xbd6): In function `handle_dir': : undefined reference to `__guard' /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/iconvconfig.o(.text+0xdc6): In function `handle_dir': : undefined reference to `__guard' /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/iconv/iconvconfig.o(.text+0xde2): In function `handle_dir': : undefined reference to `__stack_smash_handler' collect2: ld returned 1 exit status
Strangeness abounds. I just converted my desktop to nptl with no problem. Then, just did the exact same procedure on my laptop, and I'm getting this error with Xorg-x11-6.8.0-r3. Converstion process: * Add nptl USE flag (nptlonly _unset_) * emerge glibc fltk && sync && sleep 2 && reboot (on laptop) * emerge glibc fltk nvidia-glx && sync && sleep 2 && reboot (on desktop) Running with "x86" keyword on both boxes. Laptop has neomagic video chip - could the lack of a seperate opengl video driver package (i.e. nvidia) be the culprit for xorg?
Oh, and also, I didn't emerge any new headers before this occoured - bug title may not be correct.
Oh, and also FYI: I didn't emerge any new headers before this occoured - bug title may not be correct. Just enabled nptl.
please emerge gcc-config-1.3.7-r5, run gcc-config for your target toolchain, unset GCC_SPECS in your env, and then source /etc/profile that should do it
Does not work !! I have just emerged that version of gcc-config. Because I have only gcc 3.3.4 I ran "gcc-config 1". I have nothing about "GCC_SPECS" in /etc/env.d/gcc so I did not unset anything and then ran "source /etc/profile" and X keeps complaining about the __guard symbol.
I get the "undefined reference to `__guard'" while trying to emerge glibc.-2.3.4.20041102. This was after emerging the new linux26-2.6.8.1 headers. I have seen this error in the forums with users and X. Could it be something wrong with the linux26-headers themselves?
I had old 2.4 headers before emerging glibc this morning. After that X would not work as mentioned in these comments. For me the solution was to emerge an older version of glibc sys-libs/glibc-2.3.3.20040420-r2 . I even upgraded to the latest linux headers sys-kernel/linux26-headers-2.6.8.1-r1 and added support for nptl during all this and after emerging the old glibc my X now works.
Here is what I did to fix it. I changed the ebuild glibc-2.3.4.20040808-r1.ebuild to apply the glibc-2.3.2-propolice-guard-functions-v3.patch on all architectures and not just for hppa. That is, in function do_ssp_patches() comment out the lines starting with "if" and "fi". After re-emerging glibc all was working again. It has nothing to do with the new headers, I am using them now. I guess there was a reason to apply this patch only on hppa. So don't take this as a fix for the problem. It's just a hint.
Instructions per comment #12 works for me too...
A bit confused here. The last practicale comment (#12) ends with this: "So don't take this as a fix for the problem. It's just a hint." So how is this bug now marked "RESOLVED:WORKSFORME" when a true fix is not present?
Regarding #12, I have editied the ebuild however my system isn't compiling so I can't emerge it again. What can I do, and is this a proper fix (as mentioned)? Should the patch apply only to hppa archs or not?
Can we reopen the bug for further inspection? The forums suggest many people are having problems with this problem, and fixes both vary in mileage and are sketchy.
OK, tried the #12 solution - and it worked for me on my laptop. What is strange, however, is that this problem did not occur on my desktop. I'd love to know why this problem happend when it did, and not previously. There was no entry in the glibc changelog that I saw that showed this change - though I could have missed it. Thank you, Heinrich Nirschl. I think more confirmations are merited for other arches before this bug is really resolved.
Reopened, several people on the forums have reported this issue now and mileage in fixing the bug seems to differ. Additionally, rather than Linux headers as the title suggests, it does seem to be glibc
The current versions of glibc-2.3.4.20040808-r1.ebuild and glibc-2.3.4.20041102.ebuild are working. They apply the patch on all architectures but hppa. IMHO the bug can be closed now.
solar fixed this for me already
*** Bug 73526 has been marked as a duplicate of this bug. ***
