Summary: | sys-libs/glibc-2.17 breaks on arm hardfp systems w/mixed tagged libs - error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | William Throwe <wtt6> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | armin76, bugs+gentoo, kkrizka, ted.tanberry, tomwij |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
URL: | http://sourceware.org/bugzilla/show_bug.cgi?id=15006 | ||
See Also: |
http://sourceware.org/bugzilla/show_bug.cgi?id=15006 https://bugs.gentoo.org/show_bug.cgi?id=453760 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log.gz
ldconfig output LD_DEBUG=all ls readelf output upstream patch |
Description
William Throwe
2013-01-26 18:09:24 UTC
what does `gcc-config -l` show ? is your installed toolchain set to active ? what does /etc/ld.so.conf.d/05gcc-armv7a-hardfloat-linux-gnueabi.conf have ? what about `ldconfig -p` ? Created attachment 337136 [details]
ldconfig output
Looks fine as far as I can tell.
mim ~ # gcc-config -l
[1] armv7a-hardfloat-linux-gnueabi-4.5.3 *
mim ~ # cat /etc/ld.so.conf.d/05gcc-armv7a-hardfloat-linux-gnueabi.conf
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.5.3
mim ~ # ldconfig -p >ldconfig
mim ~ # grep libgcc_s ldconfig
libgcc_s.so.1 (libc6) => /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.5.3/libgcc_s.so.1
so if you delete /lib/libgcc_s.so.1 now, everything runs fine ? (In reply to comment #3) > so if you delete /lib/libgcc_s.so.1 now, everything runs fine ? Nope. Everything breaks again if I delete the symlink. I don't know if it is interesting or not, but the ldconfig -p output is the same either with or without the /lib/libgcc_s.so.1 symlink. (In reply to comment #4) if you delete it, then run `ldconfig`, does things work ? glibc should be able to locate libgcc_s.so.1 in gcc's internal dir just fine ... i'm assuming you're just running `ls` and such and not trying to reboot with a sep /usr partition (In reply to comment #5) > (In reply to comment #4) > > if you delete it, then run `ldconfig`, does things work ? glibc should be > able to locate libgcc_s.so.1 in gcc's internal dir just fine ... > Removing the symlink and then running ldconfig does not help. Still can't find libgcc_s.so.1 . > i'm assuming you're just running `ls` and such and not trying to reboot with > a sep /usr partition Yeah, just running ls and similar. I haven't tried to reboot this machine yet since installing glibc-2.17, and it doesn't have a separate /usr anyway. (In reply to comment #6) hrmph. this really really should not be the case. if you run `ldd /bin/ls`, does it show the /lib/ one ? and if you rm it, it shows not found ? can you run `LD_DEBUG=all ls` after deleting the /lib/ one (and running `ldconfig -p`) and post the output as an attachment ? Created attachment 337154 [details] LD_DEBUG=all ls (In reply to comment #7) > (In reply to comment #6) > > hrmph. this really really should not be the case. > > if you run `ldd /bin/ls`, does it show the /lib/ one ? and if you rm it, it > shows not found ? > > can you run `LD_DEBUG=all ls` after deleting the /lib/ one (and running > `ldconfig -p`) and post the output as an attachment ? Correct, except that ldd doesn't work without the symlink so I can't do that test. mim ~ # ldd /bin/ls librt.so.1 => /lib/librt.so.1 (0x2aadc000) libacl.so.1 => /lib/libacl.so.1 (0x2aaeb000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aafa000) libc.so.6 => /lib/libc.so.6 (0x2ab0d000) libpthread.so.0 => /lib/libpthread.so.0 (0x2ac45000) libattr.so.1 => /lib/libattr.so.1 (0x2ac65000) /lib/ld-linux.so.3 (0x2aaab000) mim ~ # rm /lib/libgcc_s.so.1 mim ~ # ldd /bin/ls /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory mim ~ # ldconfig -p>/dev/null mim ~ # LD_DEBUG=all ls 2>ld_debug (In reply to comment #8) i wonder if libgcc_s.so.1 or ls was built with some ELF tags that the runtime ldso uses to reject the cache entries, and then falls back to a path search and says "screw it i'll use this". earlier passes in that file indicate a bug too. for example, it should have found librt.so.1 via the cache, not via the fallback path search. could you run `readelf -Ae` on /bin/ls and /lib/librt.so.1 and /lib/libgcc.s.so.1 and post the output as an attachment ? also, run `ldconfig -pvvv` and post that as an attachment. that way it might include tag information too. Created attachment 337160 [details]
readelf output
readelf -Ae for the requested files attached.
`ldconfig -pvvv` gave the same output as `ldconfig -p`. The only difference from the previously attached ldconfig output is that it now lists ld-linux-armhf.so.3 instead of ld-linux.so.3 on the last line. I don't know why that changed. (The latter is a symlink to the former.)
(In reply to comment #10) hrm, i'm guessing this is an older system that transitioned from the old arm ldso name to the new one. if you compile a dummy app like so: echo 'main(){}' | gcc -x c - -lgcc_s -o a.out and then run `./a.out`, can it locate libgcc_s.so.1 in the internal gcc dir (i.e. rm it from /lib/ and try running it) ? if so, can you re-emerge coreutils and see if `ls` starts working ? if not, does `ldd` show a.out using ld-linux.so.3 or ld-linux-armhf.so.3 (the latter is the correct one) ? you might have to upgrade/rebuild your gcc to one that uses the new ldso name -- gcc-4.5+ in the tree should be patched now to use the new ldso name. (In reply to comment #11) > (In reply to comment #10) > > hrm, i'm guessing this is an older system that transitioned from the old arm > ldso name to the new one. > In fact, it mostly hasn't transitioned because I hit bug 434856 at the same time as the transition and everything has been broken since. > if you compile a dummy app like so: > echo 'main(){}' | gcc -x c - -lgcc_s -o a.out > > and then run `./a.out`, can it locate libgcc_s.so.1 in the internal gcc dir > (i.e. rm it from /lib/ and try running it) ? > No. It fails. > if so, can you re-emerge coreutils and see if `ls` starts working ? > > if not, does `ldd` show a.out using ld-linux.so.3 or ld-linux-armhf.so.3 > (the latter is the correct one) ? you might have to upgrade/rebuild your > gcc to one that uses the new ldso name -- gcc-4.5+ in the tree should be > patched now to use the new ldso name. It shows ld-linux.so.3 . I will try updating to gcc-4.6.3. No better with 4.6.3, even though it uses the correct ld.so name: mim ~ # echo 'main(){}' | gcc-4.5.3 -x c - -lgcc_s -o 4.5.3.out mim ~ # echo 'main(){}' | gcc-4.6.3 -x c - -lgcc_s -o 4.6.3.out mim ~ # rm /lib/libgcc_s.so.1 mim ~ # ./4.5.3.out ./4.5.3.out: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory mim ~ # ./4.6.3.out ./4.6.3.out: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory mim ~ # sln /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.5.3/libgcc_s.so.1 /lib/libgcc_s.so.1 mim ~ # ldd 4.5.3.out libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aadd000) libc.so.6 => /lib/libc.so.6 (0x2aaf0000) /lib/ld-linux.so.3 (0x2aaab000) mim ~ # ldd 4.6.3.out libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aadd000) libc.so.6 => /lib/libc.so.6 (0x2aaf0000) /lib/ld-linux-armhf.so.3 (0x2aaab000) Also, I can't change the system compiler to 4.6.3 because gcc-config removes the symlink and crashes before completing the update. (The install of 4.6.3 also removed the symlink and failed after the merge, I think because it ran gcc-config.) I recompiled with USE=vanilla, no change. However, I found this upstream bug: http://sourceware.org/bugzilla/show_bug.cgi?id=15006 If I'm reading it correctly, glibc is assuming everything on the system has been built with a binutils feature that is so new that it hasn't been released yet. yes, that looks like the same issue Created attachment 346650 [details, diff]
upstream patch
can you try this patch and see if it fixes things ? you can put it in:
/etc/portage/patches/sys-libs/glibc/
and it should get automatically applied
(In reply to comment #16) > Created attachment 346650 [details, diff] [details, diff] > upstream patch > > can you try this patch and see if it fixes things ? you can put it in: > /etc/portage/patches/sys-libs/glibc/ > and it should get automatically applied Confirmed. This fixes it. After deleting my symlinks in /usr/lib and running `LD_LIBRARY_PATH=/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2 ldconfig`, my system is working as it should. (In reply to comment #17) great ... thanks for testing http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.17/0090_all_glibc-2.17-arm-ldso.cache.patch?rev=1.1 I was hit by that bug, too. What's the easiest way to fix this? Insert the SD card into some other machine and unpack a binpkg (built on the Raspberry Pi, of course) from an older glibc version that worked? (In reply to comment #19) > I was hit by that bug, too. What's the easiest way to fix this? Insert the > SD card into some other machine and unpack a binpkg (built on the Raspberry > Pi, of course) from an older glibc version that worked? You only need to make a few symlinks: busybox ln -s /usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/*/lib*.so* /usr/lib/ Then re-emerge glibc-2.17. If you've shut down your system and can't get a prompt on it now, you'll have to put the SD card in another Linux system and make those symlinks there. Then you should be able to boot into it on the RPi and re-emerge glibc. After the glibc build has completed, you can remove the symlinks: cd /usr/lib rm $(cd /usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/* ; command ls lib*.so*) Then you should re-run ldconfig to fix your cache: LD_LIBRARY_PATH=$(echo /usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/*) ldconfig Will be fixed in the new 2.17 point release. http://sourceware.org/bugzilla/show_bug.cgi?id=15122 This did not work for me. I did the following: - created the symlinks. System works normally again. - re-emerged glibc (*) - removed the symlinks. I get the error about libgcc_s.so.1 again (*) I re-emerged glibc multiple times, updated gcc from 4.6 to 4.7, removed and re-added the symlinks several times... nothing worked. The installed ebuild is $Header: /var/cvsroot/gentoo-x86/sys-libs/glibc/glibc-2.17.ebuild,v 1.13 2013/04/28 04:00:36 vapier Exp $ so that should be the latest one with vapier's fix, correct? (In reply to comment #22) > This did not work for me. I did the following: > > - created the symlinks. System works normally again. > - re-emerged glibc (*) > - removed the symlinks. I get the error about libgcc_s.so.1 again > > (*) I re-emerged glibc multiple times, updated gcc from 4.6 to 4.7, removed > and re-added the symlinks several times... nothing worked. The installed > ebuild is > > $Header: /var/cvsroot/gentoo-x86/sys-libs/glibc/glibc-2.17.ebuild,v 1.13 > 2013/04/28 04:00:36 vapier Exp $ > > so that should be the latest one with vapier's fix, correct? Did you rebuild your ld.so.cache after deleting the symlinks? Run ldconfig (with LD_LIBRARY_PATH set to the path containing libgcc_s.so). Seems to work, thanks a lot. |