Bug 1978984
| Summary: | pax-utils: lddtree.py test fails on aarch64 and s390x due to ld.so moving from /lib64 to /lib | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dominik 'Rathann' Mierzejewski <dominik> |
| Component: | pax-utils | Assignee: | Dominik 'Rathann' Mierzejewski <dominik> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 35 | CC: | dominik, fweimer |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-09-24 09:32:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The issue seems to be that the heuristic to set ldpaths['interp'] is not correct. I'm not sure if the required information (the built-in search paths of the dynamic loader) is available in a declarative fashion. On Fedora, you could presently read the system_dirs global variable in ld.so: 198: 000000000001d1d8 20 OBJECT LOCAL DEFAULT 13 system_dirs It contains a concatenated sequence of null-terminated C strings, specifying the search directories. But this is not a public interface, of course, and even subject to optimization by GCC. Looking at system_dirs is probably a very bad idea because it's not a stable interface. I should not have suggested it. Unfortunately, the default search paths are not portable across distributions (for example, Debian's multi-arch patches aren't in upstream glibc). For Fedora, it's sufficient for now to hard-code /usr/lib for 32-bit and /usr/lib64 for 64-bit (due to UsrMove). RISC-V will need an exception, however. This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35. Closing this one as it's worked around in the spec file, we're not actually shipping the lddtree.py script and there's a bug report upstream. |
Description of problem: lddtree.py is unable to find linked objects on aarch64 and s390x with glibc-2.33.9000-15.fc35 or later. Version-Release number of selected component (if applicable): pax-utils-1.3.1-1.fc35 glibc-2.33.9000-15.fc35 How reproducible: Always. Steps to Reproduce: 1. On aarch64 or s390x install glibc-2.33.9000-15.fc35 or later 2. dnf install python3-pyelftools 3. fedpkg clone rpms/pax-utils 4. fedpkg prep 5. pax-utils-1.3.2/lddtree.py --debug /bin/bash Actual results: root = / cwd = /builddir/build/BUILD/pax-utils-1.3.2 ParseLdSoConf(//etc/ld.so.conf) glob: //etc/ld.so.conf.d/*.conf ldpaths[conf] = [] ldpaths[env] = [] argv[x] = /bin/bash +auto-root = /bin/bash globbed = /bin/bash ParseELF(/bin/bash) interp = /lib/ld-linux-aarch64.so.1 ldpaths[interp] = ['/lib', '/usr/lib'] ldpaths[rpath] = [] ldpaths[runpath] = [] FindLib(libtinfo.so.6) checking: /lib/libtinfo.so.6 checking: /usr/lib/libtinfo.so.6 FindLib(libdl.so.2) checking: /lib/libdl.so.2 checking: /usr/lib/libdl.so.2 FindLib(libc.so.6) checking: /lib/libc.so.6 checking: /usr/lib/libc.so.6 /bin/bash (interpreter => /lib/ld-linux-aarch64.so.1) libtinfo.so.6 => None libdl.so.2 => None libc.so.6 => None ld-linux-aarch64.so.1 => /lib/ld-linux-aarch64.so.1 Expected results: root = / cwd = /builddir/build/BUILD/pax-utils-1.3.2 ParseLdSoConf(//etc/ld.so.conf) glob: //etc/ld.so.conf.d/*.conf ldpaths[conf] = [] ldpaths[env] = [] argv[x] = /bin/bash +auto-root = /bin/bash globbed = /bin/bash ParseELF(/bin/bash) interp = /lib/ld-linux-aarch64.so.1 ldpaths[interp] = ['/lib', '/usr/lib'] ldpaths[rpath] = [] ldpaths[runpath] = [] FindLib(libtinfo.so.6) checking: /usr/lib64/libtinfo.so.6 -> /usr/lib64/libtinfo.so.6.2 ParseELF(/usr/lib64/libtinfo.so.6.2) FindLib(libc.so.6) checking: /usr/lib64/libc.so.6 ParseELF(/usr/lib64/libc.so.6) FindLib(libdl.so.2) checking: /usr/lib64/libdl.so.2 ParseELF(/usr/lib64/libdl.so.2) /bin/bash (interpreter => /lib/ld-linux-aarch64.so.1) libtinfo.so.6 => /usr/lib64/libtinfo.so.6 libdl.so.2 => /usr/lib64/libdl.so.2 libc.so.6 => /usr/lib64/libc.so.6 ld-linux-aarch64.so.1 => /lib/ld-linux-aarch64.so.1 Additional info: Probably related to bug 1652867.