| Summary: | Emerge of glibc-2.4-r4 fails on simple sanity tests | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christian Theune <ct> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | critical | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | LD_DEBUG log | ||
|
Description
Christian Theune
2006-11-13 09:23:38 UTC
Here are the last lines from the emerge: /var/tmp/portage/glibc-2.4-r3/work/build-default-i686-pc-linux-gnu-nptl/elf/ldconfig: Can't open configuration file /etc/ld.so.conf: No such file or directory make[1]: Leaving directory `/var/tmp/portage/glibc-2.4-r3/work/glibc-2.4' /bin/date: relocation error: /lib/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference !!! ERROR: sys-libs/glibc-2.4-r3 failed. Call stack: ebuild.sh, line 1546: Called dyn_install ebuild.sh, line 1020: Called src_install glibc-2.4-r3.ebuild, line 1272: Called toolchain-glibc_src_install glibc-2.4-r3.ebuild, line 520: Called die !!! simple run test (/bin/date) failed !!! If you need support, post the topmost build error, and the call stack if relevant. So try 2.4-r4 Sorry, didn't help. Same problem, however, I overlooked one line in the output when I pasted the first time: *** /var/tmp/portage/glibc-2.4-r4/work/build-default-i686-pc-linux-gnu-nptl/elf/ldconfig: Can't open configuration file /etc/ld.so.conf: No such file or directory make[1]: Leaving directory `/var/tmp/portage/glibc-2.4-r4/work/glibc-2.4' *** /bin/date: relocation error: /lib/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference !!! ERROR: sys-libs/glibc-2.4-r4 failed. Call stack: ebuild.sh, line 1546: Called dyn_install ebuild.sh, line 1020: Called src_install glibc-2.4-r4.ebuild, line 1251: Called toolchain-glibc_src_install glibc-2.4-r4.ebuild, line 506: Called die !!! simple run test (/bin/date) failed !!! If you need support, post the topmost build error, and the call stack if relevant. my guess is your tree is out of date ... sync it up and try again Happens with 2.4-r4 too. I've run 'emerge sync' and emerged glibc two times, (once after doing an 'emerge system') both times the error stays the same.
/var/tmp/portage/glibc-2.4-r4/work/build-default-i686-pc-linux-gnu-nptl/elf/ldconfig -r /var/tmp/portage/glibc-2.4-r4/image/ \
/lib /usr/lib
/var/tmp/portage/glibc-2.4-r4/work/build-default-i686-pc-linux-gnu-nptl/elf/ldconfig: Can't open configuration file /etc/ld.so.conf: No such file or directory
make[1]: Leaving directory `/var/tmp/portage/glibc-2.4-r4/work/glibc-2.4'
/bin/date: relocation error: /lib/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
!!! ERROR: sys-libs/glibc-2.4-r4 failed.
Call stack:
ebuild.sh, line 1546: Called dyn_install
ebuild.sh, line 1020: Called src_install
glibc-2.4-r4.ebuild, line 1255: Called toolchain-glibc_src_install
glibc-2.4-r4.ebuild, line 510: Called die
!!! simple run test (/bin/date) failed
!!! If you need support, post the topmost build error, and the call stack if relevant.
Quick update: I've updated from gcc-4.1.1 to gcc-4.1.1 without any success. I meant to say that I updated to gcc-4.1.1-r1 that doesnt make sense as /lib shouldnt be used
what does `file /bin/date` show ?
what does this show:
/var/tmp/portage/glibc-2.4-r4/image/lib/ld-linux.so.2 \
--library-path /var/tmp/portage/glibc-2.4-r4/image/lib \
/bin/date
~$ file /bin/date
/bin/date: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
~$ /var/tmp/portage/glibc-2.4-r4/image/lib/ld-linux.so.2 \
> --library-path /var/tmp/portage/glibc-2.4-r4/image/lib \
> /bin/date
bash: /var/tmp/portage/glibc-2.4-r4/image/lib/ld-linux.so.2: Datei oder Verzeichnis nicht gefunden
Looks like emerge cleaned up ... can I avoid that?
i dont think portage cleaned it up ... it would only do that after a successful merge try running `ebuild glibc-2.4-r4.ebuild clean unpack compile install` and then try the aforementioned tests again Here's the output: #/var/tmp/portage/glibc-2.4-r4/image/lib/ld-linux.so.2 --library-path /var/tmp/portage/glibc-2.4-r4/image/lib /bin/date /bin/date: relocation error: /lib/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference what does this show: ls /var/tmp/portage/glibc-2.4-r4/image/lib/ and this: /var/tmp/portage/glibc-2.4-r4/image/lib/ld-linux.so.2 --library-path \ /var/tmp/portage/glibc-2.4-r4/image/lib --list /bin/date Here it comes:
# ls /var/tmp/portage/glibc-2.4-r4/image/lib
ld-2.4.so libcrypt-2.4.so libnsl.so.1 libnss_nis-2.4.so librt-2.4.so
ld-linux.so.2 libcrypt.so.1 libnss_compat-2.4.so libnss_nisplus-2.4.so librt.so.1
libanl-2.4.so libc.so.6 libnss_compat.so.2 libnss_nisplus.so.2 libSegFault.so
libanl.so.1 libdl-2.4.so libnss_dns-2.4.so libnss_nis.so.2 libthread_db-1.0.so
libBrokenLocale-2.4.so libdl.so.2 libnss_dns.so.2 libpcprofile.so libthread_db.so.1
libBrokenLocale.so.1 libm-2.4.so libnss_files-2.4.so libpthread-2.4.so libutil-2.4.so
libc-2.4.so libmemusage.so libnss_files.so.2 libpthread.so.0 libutil.so.1
libcidn-2.4.so libm.so.6 libnss_hesiod-2.4.so libresolv-2.4.so
libcidn.so.1 libnsl-2.4.so libnss_hesiod.so.2 libresolv.so.2
# /var/tmp/portage/glibc-2.4-r4/image/lib/ld-linux.so.2 --library-path \
> /var/tmp/portage/glibc-2.4-r4/image/lib --list /bin/date
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/librt.so.1 (0x40020000)
libc.so.6 => /lib/libc.so.6 (0x40033000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40143000)
/lib/ld-linux.so.2 => /var/tmp/portage/glibc-2.4-r4/image/lib/ld-linux.so.2 (0x80000000)
so run: LD_DEBUG="all" /var/tmp/portage/glibc-2.4-r4/image/lib/ld-linux.so.2 \ --library-path /var/tmp/portage/glibc-2.4-r4/image/lib \ --list /bin/date Created attachment 102186 [details]
LD_DEBUG log
Log of LD_DEBUG run
I've got to crank up the severity a bit, as other programs *seem* to start depending on this version of glibc and I can't update. (In reply to comment #1) > /var/tmp/portage/glibc-2.4-r3/work/build-default-i686-pc-linux-gnu-nptl/elf/ldconfig: > Can't open configuration file /etc/ld.so.conf: No such file or directory Shouldn't /etc/ld.so.conf always exist? If indeed it doesn't exist, run env-update to recreate it, see if that helps. Right, but that file exists. :( ignore the ld.so.conf warning, that is normal and expected and when you ran the test, you made sure you still have all the libraries in /var/tmp/portage/glibc-2.4-r4/image/lib ? Like this? burns ~ # cd /var/tmp/portage/glibc-2.4-r4/image/lib/ burns lib # ls ld-2.4.so libmemusage.so libnss_nis.so.2 ld-linux.so.2 libm.so.6 libpcprofile.so libanl-2.4.so libnsl-2.4.so libpthread-2.4.so libanl.so.1 libnsl.so.1 libpthread.so.0 libBrokenLocale-2.4.so libnss_compat-2.4.so libresolv-2.4.so libBrokenLocale.so.1 libnss_compat.so.2 libresolv.so.2 libc-2.4.so libnss_dns-2.4.so librt-2.4.so libcidn-2.4.so libnss_dns.so.2 librt.so.1 libcidn.so.1 libnss_files-2.4.so libSegFault.so libcrypt-2.4.so libnss_files.so.2 libthread_db-1.0.so libcrypt.so.1 libnss_hesiod-2.4.so libthread_db.so.1 libc.so.6 libnss_hesiod.so.2 libutil-2.4.so libdl-2.4.so libnss_nis-2.4.so libutil.so.1 libdl.so.2 libnss_nisplus-2.4.so libm-2.4.so libnss_nisplus.so.2 It's still sitting there, I'd say. Anything I can do to help resolve this? Any more information to gather? I can't update this system anymore without working around this glibc update. I've got exactly the same error condition with glibc-2.4-r4. Should I take it that nobody's working on this, and it just means the system involved needs a full reinstallation? Or is a solution forthcoming? The system in question certainly has other stuff out of date - and the problem must lie there. But it's gonna be a hell of a lot more work to rebuild it and get everything installed the same than it would be if someone were to solve this bug sometime soon. 2.5 fails in the same way:
: /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/libc_pic.a
gcc -nostdlib -nostartfiles -r -o /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/elf/librtld.map.o '-Wl,-(' /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-allobjs.os /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/elf/librtld.mapT
/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/libc_pic.a(init-first.os):(.data+0x0): multiple definition of `__libc_multiple_libcs'
/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-allobjs.os:(.bss+0x80): first defined here
/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/libc_pic.a(_itoa.os): In function `_itoa':
_itoa.c:(.text+0x120): multiple definition of `_itoa'
/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-allobjs.os:: first defined here
/usr/lib/gcc/i586-pc-linux-gnu/3.4.5/../../../../i586-pc-linux-gnu/bin/ld: Warning: size of symbol `_itoa' changed from 181 in /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-allobjs.os to 491 in /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/libc_pic.a(_itoa.os)
collect2: ld returned 1 exit status
make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i686-pc-linux-gnu-nptl/elf/librtld.map] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.5/work/glibc-2.5/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.5/work/glibc-2.5'
make: *** [all] Error 2
!!! ERROR: sys-libs/glibc-2.5 failed.
Call stack:
ebuild.sh, line 1593: Called dyn_compile
ebuild.sh, line 951: Called src_compile
glibc-2.5.ebuild, line 1119: Called toolchain-glibc_src_compile
glibc-2.5.ebuild, line 242: Called die
your issue is unrelated to this bug report; search elsewhere to find yours You're right SpanKY. My problem was that the ebuild doesn't override -fstack-protector with -fno-stack-protector. Now, presuming you knew that, your comment "search elsewhere" was a bit less helpful than you easily could have been. But I'd found the solution meanwhile, so no matter. Since distros including Gentoo Hardened are going to default use of stack-protector, perhaps a bit more care should be taken to handle the situations where it still won't work? Sorry to clutter up this discussion, though.... if you read the other bugs covering the hardened issue you would see that it isnt so simple as "lets change this one thing here and it all magically works" src_test() is not supported in versions older than glibc-2.5-r1 ... if that version fails a test, then open a new bug report with relevant information |
