dh_shlibdeps fails to find some dependencies in cross-compilation with custom sysroot

[alejandroclaro]

I’m encountering issues with dh_shlibdeps when cross-compiling in an environment where the sysroot is not "/".

I’ve experimented with the admindir argument, but the results remain inconsistent — some dependencies are correctly found, but others are not, making the process unreliable.

My questions are:

• What is the correct way to use dh_shlibdeps in cross-compilation when the sysroot is outside the root filesystem?
• If admindir is intended to help in this scenario, what are its expected use cases, and how should it be properly configured?

Any guidance on how to properly set up dh_shlibdeps (or dpkg-shlibdeps) in such an environment would be greatly appreciated.

[nthykier]

Hi @alejandroclaro

I recommend having a look at https://wiki.debian.org/CrossCompiling

The correct way to cross build is to use a Debian system (chroot, container or similar) with Multi-Arch enabled. You will need most build-depends installed for the "host" architecture and some for the "build" architecture (per GNU autoconf definition or the DEB_{HOST,BUILD}_* variable definitions). And then when you initiate the build, you will need to pass -a<host-arch> to dpkg-buildpackage (often this is done via a wrapper like sbuild or pbuilder which uses their own command line argument to setup the environment).

The dpkg-buildpackage -a<...> part will ensure that dpkg will export the relevant ENV variables to inform the build tools (such as dpkg-shlibdeps called from dh_shlibdeps) that this is a cross build. This enables the tools to subtly change their logic - like dpkg-shlibdeps will resolve dependencies for the "DEB_HOST_ARCH" rather than the "DEB_BUILD_ARCH".

As for installing the build-dependencies, apt-get can do that via -a as long as you have declared them correctly in debian/control under Build-Depends (and its counter parts). If you are not using any chroot tooling at all, you are looking at something like:

# Setup/once 
sudo dpkg --add-architecture armhf
sudo apt-get update
sudo apt-get install build-essential crossbuild-essential-armhf

# At each build
cd <source-root>  # directory containing debian/control.
sudo apt-get build-dep -aarmhf .
CONFIG_SITE=/etc/dpkg-cross/cross-config.armhf DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -aarmhf -Pcross,nocheck

In this example, armhf is the "host" arch and you have to replace it consistently if you want the build for a different architecture. If you use a wrapper like sbuild/pbuilder, it becomes a single command line option of --host armhf or --host-arch armhf depending on the tool on top of their regular setup.

There are some more recommendations in https://wiki.debian.org/CrossBuildPackagingGuidelines. It starts off by explaining concepts that should already be covered above, so you can skip to Common problems and go down from there.

Note the package build may start to fail under this setup because path change. In a native build, DEB_HOST_* and DEB_BUILD_* are always the same. Once you start the "proper" cross-build, these variables will change. Therefore, any packaging that uses these variables might now start to fail. In general, you want to be sure to use DEB_HOST_* instead of than DEB_BUILD_* in the packaging (debian/rules, debian/*.install, etc.). I recommend you start by fixing this first in the packaging if you have any instances there (you might not have any, which would be good).

Hope that helps! :)

PS: If you are new to autoconf/Debian's terms for cross-building, take some extra time to learn it. Many cross-building stacks tends to only have two terms like "build" vs. "target", which are not typically aligned with the autoconf/Debian terms - like in autoconf/Debian, the target is almost always the wrong option. The confusion is often frustrating.

[alejandroclaro]

Thank you, @nthykier, for the detailed explanation. I really appreciate the dedication and the thorough response.

In my case, the issues I am encountering are as follows:

1. I use CMake as the build system and CPack as the packaging system.
2. The system has many dependencies, which often leads to conflicts and problems in a multi-architecture environment (e.g., some packages attempting to replace python3:amd64 with the ARM package).

The first point is manageable. I have successfully made it work both in a multiarch setup and within a separate rootfs with no significant issues, aside from the dh_shlibdeps issue where it fails to correctly identify some dependencies.

The second point is the primary concern. I have consistently searched for workarounds for the multiarch environment, but I am convinced this issue is persistent and lacks a definitive solution. Consequently, I am more inclined to get dh_shlibdeps to work within an isolated rootfs environment.

[nthykier]

Hi,

Indeed, working out the dependencies to be cross-safe is a huge part of supporting cross-compiling. If you are doing a python extension (which might be the case given your remark), you need to replace python-dev with python-dev:native, libpython-dev as an example (full table at https://wiki.debian.org/CrossBuildPackagingGuidelines#Python_extensions)

This part is not really my forte, so I cannot help here a lot. You might have better luck with debian-mentors@lists.debian.org or debian-cross@lists.debian.org.

[alejandroclaro]

Thank you @nthykier

I didn't know about those lists. I will try to get in touch with the people there.

The applications I develop are not all python extensions, but based in different stacks. Some have dependencies that are"huge" like GTKmm. The major problem is that these packages, depends of other packages, and so on, that depends on for example python and pyhton-dev.

So it has been complicated since I cannot control the whole dependency tree to ensure this can work in a multi arch environment.

I ended writing scripts, to prepare the installation of dependencies, based on 'aptitude' and fine tuned the resolvers, but this has proven to be fragile too.

[mademind122333-jp]

i solve this isseus