It would useful to have a QA check for broken soname dependencies. It's currently possible to see the broken soname dependencies on a system with this command: emerge -p --depclean --ignore-soname-deps=n These issues either indicate a simple broken soname dependency (very common for -bin packages), a portage bug/deficiency (like bug 646190), or a packaging quirk (like bug 694248).
I'm working on a patch in https://github.com/zmedico/portage/tree/bug_704320_broken_soname_dependency_qa_check and the output for maven-bin-3.6.2 (bug 704618) looks like this: > * QA Notice: Unsatisfied soname dependencies: > * > * /usr/share/maven-bin-3.6/lib/jansi-native/freebsd32/libjansi.so: libc.so.7 libutil.so.9 > * /usr/share/maven-bin-3.6/lib/jansi-native/freebsd64/libjansi.so: libc.so.7 libutil.so.9 > *
Patch posted for review: https://github.com/gentoo/portage/pull/495 https://archives.gentoo.org/gentoo-portage-dev/threads/2020-01/
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=d5dbe58beb5a4e73b919c7dbe8ed4d7b75a860f0 commit d5dbe58beb5a4e73b919c7dbe8ed4d7b75a860f0 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-01-02 23:41:45 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-01-23 06:11:53 +0000 Add QA check for unresolved soname dependencies (bug 704320) Example output for maven-bin-3.6.2 (bug 704618): * QA Notice: Unresolved soname dependencies: * * /usr/share/maven-bin-3.6/lib/jansi-native/freebsd32/libjansi.so: libc.so.7 libutil.so.9 * /usr/share/maven-bin-3.6/lib/jansi-native/freebsd64/libjansi.so: libc.so.7 libutil.so.9 * This warning comes up when a library or executable has one or more soname dependencies (found in its NEEDED.ELF.2 metadata) that could not be resolved by usual means. If you run ldd on files like these then it will report a "not found" error for each unresolved soname dependency. In order to correct problems with soname dependency resolution, use one or more of the approaches described in the following sections. Content of the NEEDED.ELF.2 metadata file may be useful for debugging purposes. Find the NEEDED.ELF.2 file in the ${D}/../build-info/ directory after the ebuild src_install phase completes, or in the /var/db/pkg/*/*/ directory for an installed package. Each line of the NEEDED.ELF.2 file contains semicolon separated values for a single ELF file. The soname dependencies are found in the DT_NEEDED column: E_MACHINE;path;DT_SONAME;DT_RUNPATH;DT_NEEDED;multilib category External dependencies For packages that install pre-built binaries, it may be possible to resolve soname dependencies simply by adding dependencies for one or more other packages that are known to provide the needed sonames. Removal of unecessary files For packages that install pre-built binaries, it may be possible to resolve soname dependencies simply by removing unnecessary files which have unresolved soname dependencies. For example, some pre-built binary packages include binaries intended for irrelevant architectures or operating systems, and these files can simply be removed because they are unnecessary. Addition of DT_RUNPATH entries If the relevant dependencies are installed in a location that is not included in the dynamic linker search path, then it's necessary for files to include a DT_RUNPATH entry which refers to the appropriate directory. The special $ORIGIN value can be used to create a relative path reference in DT_RUNPATH, where $ORIGIN is a placeholder for the directory where the file having the DT_RUNPATH entry is located. For pre-built binaries, it may be necessary to fix up DT_RUNPATH using patchelf --set-rpath. For example, use patchelf --set-rpath '$ORIGIN' if a given binary should link to libraries found in the same directory as the binary itself, or use patchelf --set-rpath '$ORIGIN/libs' if a given binary should link to libraries found in a subdirectory named libs found in the same directory as the binary itself. For binaries built from source, a flag like -Wl,-rpath,/path/of/directory/containing/libs will create binaries with the desired DT_RUNPATH entry. Addition of DT_SONAME settings If a package installs dynamic libraries which do not set DT_SONAME, then this can lead to unresolved soname dependencies. For dynamic libraries built from source, a flag like -Wl,-soname=foo.so.1 will create a DT_SONAME setting. For pre-built dynamic libraries, it may be necessary to fix up DT_SONAME using patchelf --set-soname. Adjustment to Portage soname resolution logic It may be necessary to adjust Portage soname resolution logic in order to account for special circumstances. For example, Portage soname resolution tolerates missing DT_SONAME for dynamic libraries that a package installs in a directory that its binaries reference via DT_RUNPATH. This behavior is useful for packages that have internal dynamic libraries stored in a private directory. An example is ebtables, as discussed in bug 646190. Bug: https://bugs.gentoo.org/704320 Signed-off-by: Zac Medico <zmedico@gentoo.org> doc/qa.docbook | 98 ++++++++++++++++++++++++++++ lib/_emerge/EbuildPhase.py | 63 ++++++++++++++---- lib/portage/dep/soname/SonameAtom.py | 12 ++-- lib/portage/util/_dyn_libs/soname_deps_qa.py | 98 ++++++++++++++++++++++++++++ 4 files changed, 256 insertions(+), 15 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=926daa64ce2932685e50c5b87ebe6e1f2578feb2 commit 926daa64ce2932685e50c5b87ebe6e1f2578feb2 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-01-23 06:54:10 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-01-23 07:04:32 +0000 sys-apps/portage: Bump to version 2.3.85 #615594 dosym: revert deprecated prefix compat #704256 emerge-webrsync: chmod 755 temp dir #704320 Add QA check for unresolved soname dependencies #704848 doebuild: export SANDBOX_LOG=${T}/sandbox.log #705986 solve pypy / pypy-exe dependency cycle Bug: https://bugs.gentoo.org/706142 Bug: https://bugs.gentoo.org/615594 Bug: https://bugs.gentoo.org/704256 Bug: https://bugs.gentoo.org/704320 Bug: https://bugs.gentoo.org/704848 Bug: https://bugs.gentoo.org/705986 Package-Manager: Portage-2.3.85, Repoman-2.3.20 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-2.3.85.ebuild | 276 +++++++++++++++++++++++++++++++++ 2 files changed, 277 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=9d28f5168c11fa689a1f3061fc9a8c8220ff8374 commit 9d28f5168c11fa689a1f3061fc9a8c8220ff8374 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-02-08 23:27:40 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-02-08 23:38:11 +0000 Support FEATURES=qa-unresolved-soname-deps (bug 708448) Support FEATURES=qa-unresolved-soname-deps so that it's possible to disable the QA warning that was introduced for bug 704320. This is useful for systems that may have incomplete PROVIDES metadata due to alternative package managers or experimentation with a new architecture. Bug: https://bugs.gentoo.org/708448 Bug: https://bugs.gentoo.org/704320 Signed-off-by: Zac Medico <zmedico@gentoo.org> cnf/make.globals | 3 ++- lib/_emerge/EbuildPhase.py | 13 ++++++++----- lib/portage/const.py | 1 + man/make.conf.5 | 4 ++++ 4 files changed, 15 insertions(+), 6 deletions(-)
