Bug#977308: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
On 2020-12-18, at 15:32:01 +0100, Andreas Tille wrote: > I tried no override_dh_shlibdeps in shasta debian/rules, which has > lead to: > > dpkg-shlibdeps: error: cannot find library > /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so > needed by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' > abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: error: cannot continue due to the error above Note: > libraries are not searched in other binary packages that do not have > any shlibs or symbols file. To help dpkg-shlibdeps find private > libraries, you might need to use -l. > dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/shasta.substvars > debian/shasta/usr/bin/shasta returned exit code 2 > dh_shlibdeps: error: Aborting due to earlier error > > and in the pbuilder chroot I also tried the there commands I added to > the comment in > > > https://salsa.debian.org/med-team/shasta/-/commit/366edd672be428cc553b34b99bc614aa698175d6 > > with no success - dpkg-shlibdeps simply did not found the shared > library which exists at the said place. I wonder what might be wrong > here and how to fix this. If you haven't got this sorted yet, try the attached patch. It also corrects the SONAME of shasta.so. It does mean there's an RPATH in the executable, however. The problem with the previous solution is that it sets the NEEDED value in the executable to the absolute path of the shared library, instead of the SONAME, so it didn't matter what directory was passed, dpkg-shlibdeps wouldn't find a library with the right SONAME. J. diff --git a/debian/rules b/debian/rules index 0e286eb38f66..f1593bfc0179 100755 --- a/debian/rules +++ b/debian/rules @@ -9,6 +9,7 @@ include /usr/share/dpkg/default.mk export DEB_BUILD_MAINT_OPTIONS=hardening=+all DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) +MULTIARCH_SONAME = shasta.cpython-$(shell py3versions -vd | sed 's/\.//')-$(DEB_HOST_MULTIARCH).so %: dh $@ --with python3,sphinxdoc @@ -24,22 +25,23 @@ override_dh_auto_build: find . -name "shasta.so" -exec cp {} docs/PythonApi/ \; PYTHONPATH=docs/PythonApi/ python3 -m sphinx -N -bhtml docs/PythonApi/ build/html # HTML generator +override_dh_python3: + dh_python3 + patchelf \ + --set-soname $(MULTIARCH_SONAME) \ + $(CURDIR)/debian/python3-shasta/usr/lib/python3/dist-packages/$(MULTIARCH_SONAME) + override_dh_install-arch: dh_install -a # Rename shastaDynamic to shasta for ease mv debian/shasta/usr/bin/shastaDynamic debian/shasta/usr/bin/shasta # The library is in a more unusual place (nested within /usr/lib), so modify # the ELF - chrpath -d debian/shasta/usr/bin/shasta - patchelf --replace-needed shasta.so /usr/lib/python3/dist-packages/shasta.cpython-`py3versions -vd | sed 's/\.//'`-${DEB_HOST_MULTIARCH}.so \ + chrpath -r /usr/lib/python3/dist-packages \ + debian/shasta/usr/bin/shasta + patchelf \ + --replace-needed shasta.so $(MULTIARCH_SONAME) \ debian/shasta/usr/bin/shasta - -override_dh_shlibdeps: - # Tried: - #dh_shlibdeps -v -Lpython3-shasta - #dh_shlibdeps -v -l/usr/lib/python3/dist-packages - #dh_shlibdeps -v -l$(CURDIR)/debian/python3-shasta/usr/lib/python3/dist-packages - # but all failed :-( override_dh_missing: # No need to install docker files signature.asc Description: PGP signature
Bug#977308: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
On Fri, Dec 18, 2020 at 04:07:50PM +0100, Andreas Tille wrote: > On Fri, Dec 18, 2020 at 07:37:12PM +0500, Andrey Rahmatullin wrote: > > On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote: > > > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead > > > to: > > > > > > dpkg-shlibdeps: error: cannot find library > > > /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so > > > needed by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi: > > >'0201003e'; RPATH: '') > > Why are you linking an executable to a Python binary module? > > That's a good question. Its actually not me who did this. I think > that's done here: > >https://salsa.debian.org/med-team/shasta/-/blob/master/debian/rules#L27 Eww. But dynamicLibrary/README.md says: """ This directory builds the Shasta dynamic library `shasta.so`. This library is used in three ways: * It is linked in by the shasta dynamic executable `shastaDynamic`. * It can be imported by a python script via `import shasta` to provide Shasta Python bindings. * It can be statically linked in by other C++ code outside Shasta that uses Shasta as a library. """ So this sharing seems to be by design. That's unfortunate (can't say I'm surprised, though). > but I admit I have no idea why Shayan did so. Well, otherwise the binary wouldn't find the library. > I wonder what might be the proper way to do this to share the library > between Python modules and the executable. The proper way is to separate the common code from the Python bindings and link this correctly separated shared library into both the executable and the binary module libraries. -- WBR, wRAR signature.asc Description: PGP signature
Bug#977308: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
On Fri, Dec 18, 2020 at 07:37:12PM +0500, Andrey Rahmatullin wrote: > On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote: > > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead > > to: > > > > dpkg-shlibdeps: error: cannot find library > > /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed > > by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi: > > '0201003e'; RPATH: '') > Why are you linking an executable to a Python binary module? That's a good question. Its actually not me who did this. I think that's done here: https://salsa.debian.org/med-team/shasta/-/blob/master/debian/rules#L27 but I admit I have no idea why Shayan did so. I wonder what might be the proper way to do this to share the library between Python modules and the executable. Kind regards Andreas. -- http://fam-tille.de
Bug#977308: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote: > Hi, > > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead > to: > > dpkg-shlibdeps: error: cannot find library > /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed > by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi: > '0201003e'; RPATH: '') Why are you linking an executable to a Python binary module? -- WBR, wRAR signature.asc Description: PGP signature
Bug#977308: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
Hi, I tried no override_dh_shlibdeps in shasta debian/rules, which has lead to: dpkg-shlibdeps: error: cannot find library /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: error: cannot continue due to the error above Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file. To help dpkg-shlibdeps find private libraries, you might need to use -l. dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/shasta.substvars debian/shasta/usr/bin/shasta returned exit code 2 dh_shlibdeps: error: Aborting due to earlier error and in the pbuilder chroot I also tried the there commands I added to the comment in https://salsa.debian.org/med-team/shasta/-/commit/366edd672be428cc553b34b99bc614aa698175d6 with no success - dpkg-shlibdeps simply did not found the shared library which exists at the said place. I wonder what might be wrong here and how to fix this. Kind regards Andreas. On Fri, Dec 18, 2020 at 06:03:30PM +0530, Nilesh Patra wrote: > Hi Andreas, > > On Fri, 18 Dec 2020 at 15:53, Andreas Tille wrote: > > > Control: tags -1 help > > > > Hi, > > > > I tried to fix the issue by making dh_shlibdeps work. In > > > > > > https://salsa.debian.org/med-team/shasta/-/commit/366edd672be428cc553b34b99bc614aa698175d6 > > > > I documented what I tried but all failed and I think the key to this bug > > is just making it work. > > > > Any idea? > > > > I've no clue. The "-l" flag doesn't seem to work somehow. May I suggest > forwarding it to the list? I'm positive that Aaron (ucko) will definitely > know a good workaround for this bit. > Also another request: Could you please as well attach the failing logs in > future RFHs? This saves atleast one build for the others. Consider my best > of intentions. > > Regards -- http://fam-tille.de