Somehow one of the "emerge -b -n world" runs of the last week has completely broken my gentoo/ppc64 installation. About every package I'm emerging ever since contains unresolved symbols. Example: screen eoor!ciahnu portage # emerge -b screen [...] root@vishnu portage # screen screen: symbol lookup error: screen: undefined symbol: tgetnum root@vishnu portage # ldd `which screen` libutil.so.1 => /lib/libutil.so.1 (0x000000800002a000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x000000800003c000) libpam.so.0 => /lib/libpam.so.0 (0x000000800007d000) libc.so.6 => /lib/libc.so.6 (0x0000008000099000) libdl.so.2 => /lib/libdl.so.2 (0x0000008000216000) /lib64/ld64.so.1 (0x0000008000000000) So it doesn't have a ld-dependency to libncurses, which is installed just fine: root@vishnu portage # ls -l /lib/libncurses* lrwxrwxrwx 1 root root 15 Jun 18 18:50 /lib/libncurses.so -> libncurses.so.5 lrwxrwxrwx 1 root root 17 Jun 18 18:50 /lib/libncurses.so.5 -> libncurses.so.5.4 -rwxr-xr-x 1 root root 468000 Jun 18 18:49 /lib/libncurses.so.5.4 lrwxrwxrwx 1 root root 16 Jun 18 18:50 /lib/libncursesw.so -> libncursesw.so.5 lrwxrwxrwx 1 root root 18 Jun 18 18:50 /lib/libncursesw.so.5 -> libncursesw.so.5.4 -rwxr-xr-x 1 root root 517176 Jun 18 18:49 /lib/libncursesw.so.5.4 Example: vim root@vishnu portage # vim vim: symbol lookup error: vim: undefined symbol: pthread_create Again, the same, 'ldd' of the executable doesn't show any ld-dependency to libpthreads (which is installed). I've re-emerged gcc, binutils, glibc, libtool, portage. No change. Reproducible: Always Steps to Reproduce: Run gentoo/ppc64 and emerge some random ebuilds. Tested with proftpd, vim and screen. Actual Results: Missing ld-dependencies Expected Results: correctly linked executable
If I manually LD_PRELOAD the respective missing library, the programs run just fine. Gentoo Base System version 1.6.12 Portage 2.0.51.22-r2 (default-linux/ppc64/2005.0, gcc-3.4.4, glibc-2.3.4.20041102-r1, 2.6.10gm1 ppc64) ================================================================= System uname: 2.6.10gm1 ppc64 PPC970FX, altivec supported dev-lang/python: 2.2.3-r5, 2.3.5 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.90.0.3-r5 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="ppc64" AUTOCLEAN="yes" CBUILD="powerpc64-unknown-linux-gnu" CFLAGS="-O2" CHOST="powerpc64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage_overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="ppc64 64 aac aalib alsa altivec apache2 async audiofile berkdb bitmap-fonts bzlib cdparanoia cdr cdrom chroot clamav crypt curl cyrus dvdr dvdread emboss ethereal exim exiscan exiscan-acl extensions fortran ftp gd gdbm gif hardened ieee1394 imap innodb ipv6 ipv6arpa jpeg ldap lmtp lzo mailbox maildir maildrop mbox mime mpeg mpeg4 mysql nagios-dns nagios-ntp nagios-ping nagios-ssh ncurses net nls objc ogg openssh pam pcap pcre pdflib perl png postgres python readline sasl serial slang ssl tcpd truetype truetype-fonts type1-fonts unicode vorbis xine xinerama xml2 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS
Ok, I found the culprit: It's gcc/ld from gcc-3.4.4. When it links a .o file into an executable, it doesn't complain about unresolved symbols. Only when executing the resulting executable, the dynamic linker generates an error. This obviously leads to autoconf problems, since it detects presence of a symbol by checking for linker errors. since the linker never fails, it detects the presence of symbols that don't exist. unmerging gcc-3.4.4 and going back to gcc-3.4.3-r1 solved the problem. Please immediately disable gcc-3.4.4 for ppc64 !
adding "gcc" to the summary line.
gcc 3.4.4 is working fine on a number of systems here. What does gcc-config -l show?
Marking this as need info. Any comments/thoughts Harald?
the compiled gcc-3.4.4 package can be found at ftp://ftp.gpl-devices.org/outgoing/gcc-3.4.4.tbz2 It doesn't contain any "gcc-config" program.
gcc-config is a programm to manage various versions from gcc, which are installed on your system. my output looks like this at the moment: $ gcc-config -l [1] powerpc64-unknown-linux-gnu-3.4.6 [2] powerpc64-unknown-linux-gnu-3.4.6-hardened [3] powerpc64-unknown-linux-gnu-3.4.6-hardenednopie [4] powerpc64-unknown-linux-gnu-3.4.6-hardenednopiessp [5] powerpc64-unknown-linux-gnu-3.4.6-hardenednossp [6] powerpc64-unknown-linux-gnu-4.1.0 * $ The * indicates that I'm currently using "powerpc64-unknown-linux-gnu-4.1.0". please post your output.
no response in a long time -> NEEDINFO again
