Summary: | sys-libs/glibc: hardfp ldso rename sometimes causes binaries to segfault when mixing old/new ldso names | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | William Throwe <wtt6> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | arm |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | glib-2.17.log.gz |
Description
William Throwe
2012-09-13 03:23:55 UTC
Finally got around to investigating this some more. The problem persists with glibc 2.15-r3, but goes away with USE=vanilla, so this is caused by one of Gentoo's patches. Unfortunately, with 68 patches and glibc taking a few hours to build, I'm not sure when I'll have the time to determine which one is the problem. Hi William, Which EfikaMX are you having this issue on (is it a smarttop or a smartbook, if smarttop is it a TO2 or a TO3?) I can't reproduce this issue here at all, but I don't think I have a smartbook around that had a 2.14 glibc that was upgraded to 2.15, they are all done with newer stages that started with a 2.15 glibc. (In reply to comment #1) so try glibc-2.17 (In reply to comment #2) > Hi William, > > Which EfikaMX are you having this issue on (is it a smarttop or a smartbook, > if smarttop is it a TO2 or a TO3?) I can't reproduce this issue here at > all, but I don't think I have a smartbook around that had a 2.14 glibc that > was upgraded to 2.15, they are all done with newer stages that started with > a 2.15 glibc. My machine is a smartbook. (In reply to comment #3) > (In reply to comment #1) > > so try glibc-2.17 Will do. Might take me a few days. Created attachment 335820 [details]
glib-2.17.log.gz
glibc-2.17 fails a preinst sanity check:
/bin/date: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
* ERROR: sys-libs/glibc-2.17 failed (preinst phase):
* simple run test (/bin/date) failed
Let me know if I should file a separate bug for this.
(In reply to comment #5) yes, that's a different bug. please file a new report. (In reply to comment #6) > (In reply to comment #5) > > yes, that's a different bug. please file a new report. Filed as bug #453760. Alright, I think I've sort of figured this out. I ran a binary search on the patches, and everything seems to work if I exclude just 6226_all_arm-glibc-2.15-hardfp.patch . As far as I can tell, all this patch does is rename ld-linux.so.3 to ld-linux-armhf.so.3 and change its SONAME. After recompiling again with the patch, I noticed that some libraries and executables have NEEDED entries for ld-linux.so.3, and when run with the new ld-linux-armhf.so.3 many of them segfault. I do not know why these aren't just failing at runtime link because the SONAME of ld-linux changed, but they aren't. This is presumably also why revdep-rebuild doesn't detect them. One of these libraries is libstdc++.so. Installing a newer slot of gcc (so the newer libstdc++.so is used) makes groff stop segfaulting. The openssh executables have the NEEDED entry, and remerging openssh makes them stop segfaulting. It looks like the problem will be solved if I reinstall everything with NEEDED entries for ld-linux.so.3. Assuming that works, I'm not sure if this bug is worth tracking down any further. If anyone wants to, I'm happy to provide any information they need, but if not feel free to close the bug. (I'll reopen if recompiling things doesn't fix it.) I won't have time to recompile everything until this weekend, so if you want more information try to ask before then. (And it seems that I can duplicate the problem with new executables by using a copy of the old ld-linux.so.3, so I can give some help afterwards using that.) (In reply to comment #8) yes, what you describe sounds logical. if you try to load the same ELF multiple times, things will probably crash. things continue to work because the system installs a symlink from the old ldso name to the new ldso name in /lib/. the only real fix is to rebuild everything. this is a one time penalty and doesn't affect too many people. |