| Summary: | =sys-libs/glibc-2.14.1-r3 causes segfaults on sparc64 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | seraph <seraph> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | critical | CC: | dogshu, jackhill, sparc |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | Sparc64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 430346 | ||
| Bug Blocks: | |||
| Attachments: | build errors | ||
|
Description
seraph@xs4all.nl
2012-05-27 14:03:57 UTC
your `emerge --info` says glibc-2.15. i'm guessing that isn't the same system you're describing crashing with glibc-2.14 ? It is the same system, (I actually get it on all my Sparc systems, this is but one of them), just after I upgraded to unstable glibc-2.15 to see if it had the same problem. (It doesn't, I only get it with 2.14.) I can revert the system to glibc-2.13, I still have that situation on a backup, but I doubt that changes the output of emerge --info significantly. Just to be perfectly clear: The problem occurred when I upgraded glibc from (stable) 2.13 to (stable) 2.14. It did not happen when I upgraded from (stable) 2.13 to (unstable) 2.15. I've tried five times; twice on this system and three times on three other Sparc64 systems, always with the same result: an unusable system. I have *not* attempted anything stupid like downgrade glibc, it was a regular upgrade (emerge --update --deep @system) every time. Created attachment 313671 [details]
build errors
Im seeing similar errors on compile phase. (see attached logs) Ive tried sane CHOSTS and nor MAKEOPTS. I have simlar emerge --info as below. I'm continuing to investigate In my case the compile actually completes, the segfaults happen after the new library files are copied into place and affect most commands, not just the build. Yep, same problem here. I was wondering what hosed my system. Good to know upgrading to glibc-2.15 resolves this. Apparently glibc 2.14 installs, but then all commands start failing and the symlinks aren't updated. From a static busybox shell on a hosed system: ~ # ls -l /etc/make.profile lrwxrwxrwx 1 root root 63 Jun 7 17:39 /etc/make.profile -> /usr/portage/profiles/default/linux/sparc/experimental/multilib ~ # /bin/bash sh: /bin/bash: not found ~ # ls -l /bin/bash -rwxr-xr-x 1 root root 691156 Mar 28 21:05 /bin/bash ~ # ls -l /lib32/ | grep 2.13 lrwxrwxrwx 1 root root 10 Jun 7 17:39 ld-linux.so.2 -> ld-2.13.so lrwxrwxrwx 1 root root 23 Jun 7 17:39 libBrokenLocale.so.1 -> libBrokenLocale-2.13.so lrwxrwxrwx 1 root root 14 Jun 7 17:39 libanl.so.1 -> libanl-2.13.so lrwxrwxrwx 1 root root 12 Jun 7 17:39 libc.so.6 -> libc-2.13.so lrwxrwxrwx 1 root root 15 Jun 7 17:39 libcidn.so.1 -> libcidn-2.13.so lrwxrwxrwx 1 root root 16 Jun 7 17:39 libcrypt.so.1 -> libcrypt-2.13.so lrwxrwxrwx 1 root root 13 Jun 7 17:39 libdl.so.2 -> libdl-2.13.so lrwxrwxrwx 1 root root 12 Jun 7 17:39 libm.so.6 -> libm-2.13.so lrwxrwxrwx 1 root root 14 Jun 7 17:39 libnsl.so.1 -> libnsl-2.13.so lrwxrwxrwx 1 root root 21 Jun 7 17:39 libnss_compat.so.2 -> libnss_compat-2.13.so lrwxrwxrwx 1 root root 18 Jun 7 17:39 libnss_dns.so.2 -> libnss_dns-2.13.so lrwxrwxrwx 1 root root 20 Jun 7 17:39 libnss_files.so.2 -> libnss_files-2.13.so lrwxrwxrwx 1 root root 21 Jun 7 17:39 libnss_hesiod.so.2 -> libnss_hesiod-2.13.so lrwxrwxrwx 1 root root 18 Jun 7 17:39 libnss_nis.so.2 -> libnss_nis-2.13.so lrwxrwxrwx 1 root root 22 Jun 7 17:39 libnss_nisplus.so.2 -> libnss_nisplus-2.13.so lrwxrwxrwx 1 root root 18 Jun 7 17:39 libpthread.so.0 -> libpthread-2.13.so lrwxrwxrwx 1 root root 17 Jun 7 17:39 libresolv.so.2 -> libresolv-2.13.so lrwxrwxrwx 1 root root 13 Jun 7 17:39 librt.so.1 -> librt-2.13.so lrwxrwxrwx 1 root root 15 Jun 7 17:39 libutil.so.1 -> libutil-2.13.so ~ # ls -l /lib32/ | grep 2.14 -rwxr-xr-x 1 root root 142452 May 14 00:51 ld-2.14.1.so -rwxr-xr-x 1 root root 9504 May 14 00:51 libBrokenLocale-2.14.1.so -rwxr-xr-x 1 root root 9976 May 14 00:51 libanl-2.14.1.so -rwxr-xr-x 1 root root 1468020 May 14 00:51 libc-2.14.1.so -rwxr-xr-x 1 root root 190028 May 14 00:51 libcidn-2.14.1.so -rwxr-xr-x 1 root root 34308 May 14 00:51 libcrypt-2.14.1.so -rwxr-xr-x 1 root root 18008 May 14 00:51 libdl-2.14.1.so -rwxr-xr-x 1 root root 805328 May 14 00:51 libm-2.14.1.so -rwxr-xr-x 1 root root 84692 May 14 00:51 libnsl-2.14.1.so -rwxr-xr-x 1 root root 34760 May 14 00:51 libnss_compat-2.14.1.so -rwxr-xr-x 1 root root 18088 May 14 00:51 libnss_dns-2.14.1.so -rwxr-xr-x 1 root root 51044 May 14 00:51 libnss_files-2.14.1.so -rwxr-xr-x 1 root root 18108 May 14 00:51 libnss_hesiod-2.14.1.so -rwxr-xr-x 1 root root 42888 May 14 00:51 libnss_nis-2.14.1.so -rwxr-xr-x 1 root root 51052 May 14 00:51 libnss_nisplus-2.14.1.so -rwxr-xr-x 1 root root 119341 May 14 00:51 libpthread-2.14.1.so -rwxr-xr-x 1 root root 75924 May 14 00:51 libresolv-2.14.1.so -rwxr-xr-x 1 root root 35276 May 14 00:51 librt-2.14.1.so -rwxr-xr-x 1 root root 9924 May 14 00:51 libutil-2.14.1.so ~ # if glibc-2.15 works, then i'd say let's not bother looking into 2.14 since we want to stabilize 2.15 now (bug 430346) My testing system has already been running on 2.15-r2 since this issue, and I have just finished updating the other three. No issues so far, it all seems dandy. (In reply to comment #9) thanks for following up! |
