You spend all morning setting up a multi-arch environment, and you’re certain you added the arm64 architecture to your x86_64 Debian host. You run your update, install the package, and everything looks golden. Then you try to run the binary, and it fails with a cryptic file not found error. This bit me in prod during a container build migration, and it turns out APT doesn’t always complain when it pulls a foreign architecture package into a directory where the loader can’t actually reach it.

Why multi-arch isn’t as transparent as the man page claims

When you add an architecture with dpkg, APT starts looking at those foreign repositories. But it doesn’t automatically ensure that the dependency tree is sane across architectures. If you’re mixing libraries, you often end up with a library in /usr/lib/arm-linux-gnueabihf/ that your default system path doesn’t prioritize, or worse, doesn’t even know exists. It’s not a failure, it’s a quiet drift.

dpkg --add-architecture arm64
apt update
apt install libssl-dev:arm64

• Check /var/lib/dpkg/arch to see what the system thinks is enabled
• Verify your sources.list actually includes the arch specifiers for non-native repos
• Use ldconfig -p to verify if the foreign library is even hitting the linker cache

If you are deep in the weeds of cross-compilation or building rootfs images, stop relying on simple installs. Always audit your linker path with ldd on the resulting binary before you push that image to a registry. If the linker says it can’t find the shared objects, you know exactly which architecture check you missed.