Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
alejandroclaro opened this issue Feb 13, 2025 · 1 comment

Comments

@alejandroclaro
Copy link

alejandroclaro commented Feb 13, 2025

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants