Summary: | Received "ERROR: sys-libs/glibc-2.3.4.20040808-r1 failed." When building stage1 from Universal CD | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | todd <toddenglish> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED WORKSFORME | ||
Severity: | major | CC: | eradicator, j_gentoo, pacopablo |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
todd
2005-01-26 13:44:57 UTC
please attach emerge info. I had a similar failure with glibc-2.3.4.20040808-r1 on amd64. I would attach my emerge info but the build failure left my system without a working libc, so emerge (and every other executable) just segfaults. This package should be masked immediately on amd64. --- /lib/ >>> /lib/libc-2.3.4.so >>> /lib/ld-2.3.4.so >>> /lib/libpcprofile.so >>> /lib/libBrokenLocale-2.3.4.so >>> /lib/libm-2.3.4.so >>> /lib/libdl-2.3.4.so >>> /lib/libmemusage.so >>> /lib/libcrypt-2.3.4.so >>> /lib/libpthread-2.3.4.so >>> /lib/libresolv-2.3.4.so >>> /lib/libnss_dns-2.3.4.so >>> /lib/libanl-2.3.4.so >>> /lib/libnss_files-2.3.4.so >>> /lib/librt-2.3.4.so >>> /lib/libpthread.so.0 -> libpthread-2.3.4.so >>> /lib/libSegFault.so >>> /lib/ld-linux-x86-64.so.2 -> ld-2.3.4.so >>> /lib/libnss_hesiod-2.3.4.so >>> /lib/libnsl-2.3.4.so >>> /lib/libnss_nis-2.3.4.so >>> /lib/libnss_nisplus-2.3.4.so >>> /lib/libnss_compat-2.3.4.so >>> /lib/libutil-2.3.4.so >>> /lib/libc.so.6 -> libc-2.3.4.so >>> /lib/libBrokenLocale.so.1 -> libBrokenLocale-2.3.4.so >>> /lib/libm.so.6 -> libm-2.3.4.so >>> /lib/libdl.so.2 -> libdl-2.3.4.so >>> /lib/libcrypt.so.1 -> libcrypt-2.3.4.so >>> /lib/libresolv.so.2 -> libresolv-2.3.4.so >>> /lib/libnss_dns.so.2 -> libnss_dns-2.3.4.so >>> /lib/libanl.so.1 -> libanl-2.3.4.so >>> /lib/libnss_files.so.2 -> libnss_files-2.3.4.so >>> /lib/librt.so.1 -> librt-2.3.4.so >>> /lib/libthread_db-1.0.so >>> /lib/libnss_hesiod.so.2 -> libnss_hesiod-2.3.4.so >>> /lib/libnsl.so.1 -> libnsl-2.3.4.so >>> /lib/libnss_nis.so.2 -> libnss_nis-2.3.4.so >>> /lib/libnss_nisplus.so.2 -> libnss_nisplus-2.3.4.so >>> /lib/libnss_compat.so.2 -> libnss_compat-2.3.4.so >>> /lib/libutil.so.1 -> libutil-2.3.4.so >>> /lib/libthread_db.so.1 -> libthread_db-1.0.so --- /etc/ >>> /etc/rpc >>> /etc/locales.build >>> /etc/nscd.conf --- /etc/init.d/ >>> /etc/init.d/nscd --- /sbin/ >>> /sbin/ldconfig >>> /sbin/sln !!! FAILED postinst: 2816 Joshua, can you run: $ sash -a $ ldd /bin/cat $ ls -l /lib/libc* # sash -a Stand-alone shell (version 3.7) Built-in commands are aliased to standard commands $ ldd /bin/cat pid 30330: killed by signal 11 $ ls -l /lib/libc* -rwxr-xr-x 1 root root 1243240 Jan 30 20:34 libc-2.3.4.so lrwxrwxrwx 1 root root 13 Jan 30 20:35 libc.so.6 -> libc-2.3.4.so lrwxrwxrwx 1 root root 11 Nov 10 00:48 libcap.so -> libcap.so.1 lrwxrwxrwx 1 root root 14 Nov 10 00:48 libcap.so.1 -> libcap.so.1.10 -rwxr-xr-x 1 root root 12824 Nov 10 00:48 libcap.so.1.10 -rwxr-xr-x 1 root root 191576 Nov 10 00:04 libcidn-2.3.4.so lrwxrwxrwx 1 root root 16 Nov 10 00:04 libcidn.so.1 -> libcidn-2.3.4.so lrwxrwxrwx 1 root root 15 Nov 1 09:16 libcom_err.so -> libcom_err.so.2 lrwxrwxrwx 1 root root 17 Nov 1 09:16 libcom_err.so.2 -> libcom_err.so.2.1 -rwxr-xr-x 1 root root 8752 Nov 1 09:16 libcom_err.so.2.1 lrwxrwxrwx 1 root root 15 Nov 3 23:25 libcrack.so -> libcrack.so.2.7 lrwxrwxrwx 1 root root 15 Nov 3 23:25 libcrack.so.2 -> libcrack.so.2.7 -rwxr-xr-x 1 root root 35568 Nov 3 23:25 libcrack.so.2.7 -rwxr-xr-x 1 root root 23376 Jan 30 20:34 libcrypt-2.3.4.so lrwxrwxrwx 1 root root 17 Jan 30 20:35 libcrypt.so.1 -> libcrypt-2.3.4.so lrwxrwxrwx 1 root root 17 Nov 1 08:38 libcurses.so -> libncurses.so.5.4 $ /lib/libc-2.3.4.so GNU C Library 20040808 release version 2.3.4, by Roland McGrath et al. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7). Compiled on a Linux 2.6.8 system on 2005-01-30. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. What about: $ ls -l /lib/ld-* $ /lib/ld-linux.so.2 $ /lib/ld-linux-x86-64.so.2 # ldd /bin/cat That died? ldd is staticly linked... hmm... Perhaps this should be in separate bug since this happened on an already installed and working system (I was in a hurry to file the bug case Firefox was running before the borked libc install and still working) $ ls -l /lib/ld-* -rwxr-xr-x 1 root root 91896 Jan 30 20:34 ld-2.3.4.so lrwxrwxrwx 1 root root 11 Jan 30 20:35 ld-linux-x86-64.so.2 -> ld-2.3.4.so lrwxrwxrwx 1 root root 33 Nov 1 08:41 ld-linux.so.2 -> /emul/linux/x86/lib/ld-linux.so.2 $ /lib/ld-linux.so.2 -l -l: error while loading shared libraries: -l: cannot open shared object file: No such file or directory $ /lib/ld-linux-x86-64.so.2 -l -l: error while loading shared libraries: -l: cannot open shared object file: No such file or directory $ ldd pid 544: killed by signal 11 There was no '-l' after the calls to /lib/ld-linux.so.2 and the other... Can you pleasse run: $ ls -ld /lib* $ /lib/ld-2.3.4.so $ /lib64/ld-2.3.4.so Running them without any parameters seems kinda pointless but sure... $ ls -ld /lib* drwxr-xr-x 9 root root 4096 Jan 30 20:35 lib lrwxrwxrwx 1 root root 19 Nov 1 08:41 lib32 lrwxrwxrwx 1 root root 3 Jun 12 06:42 lib64 $ /lib/ld-2.3.4.so Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked `ld.so', the helper program for shared library executables. This program usually lives in the file `/lib/ld.so', and special directives in executable files using ELF shared libraries tell the system's program loader to load the helper program from this file. This helper program loads the shared libraries needed by the program executable, prepares the program to run, and runs it. You may invoke this helper program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses this helper program from the file you specified, instead of the helper program file specified in the executable file you run. This is mostly of use for maintainers to test new versions of this helper program; chances are you did not intend to run this program. --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we can handle --library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH --inhibit-rpath LIST ignore RUNPATH and RPATH information in object names in LIST $ /lib64/ld-2.3.4.so Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked `ld.so', the helper program for shared library executables. This program usually lives in the file `/lib/ld.so', and special directives in executable files using ELF shared libraries tell the system's program loader to load the helper program from this file. This helper program loads the shared libraries needed by the program executable, prepares the program to run, and runs it. You may invoke this helper program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses this helper program from the file you specified, instead of the helper program file specified in the executable file you run. This is mostly of use for maintainers to test new versions of this helper program; chances are you did not intend to run this program. --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we can handle --library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH --inhibit-rpath LIST ignore RUNPATH and RPATH information in object names in LIST $ why are /lib and /lib64 separate directories? Do you have /lib64/ld-linux-x86-64.so.2 If not, do: ln -s ld-2.3.4.so /lib64/ld-linux-x86-64.so.2 /lib and /lib64 are not separate directories. drwxr-xr-x 9 root root 4096 Jan 30 20:35 lib lrwxrwxrwx 1 root root 19 Nov 1 08:41 lib32 -> /emul/linux/x86/lib lrwxrwxrwx 1 root root 3 Jun 12 06:42 lib64 -> lib $ ls /lib64/*ld* ld-2.3.4.so ld-linux-x86-64.so.2 ld-linux.so.2 is this still an issue with never versions? The issue was having on amd64 has been resolved. Jermey and I worked on it via IRC and the cause was a borked converstion from nptlonly to -nptlonly. I've observered similar problems with new versions of glibc going through a similar change but that's really only a documentation bug (if any). Was Todd's issue ever resolved? closing... |