Re: binutils and llvm for cross-building

[Helmut Grohne <helmut@subdivi.de>]

Hi Dima,

On Fri, Sep 05, 2025 at 11:30:15AM -0700, Dima Kogan wrote:
> - nm lives in the binutils package. I can
>   Build-Depends:binutils-for-host and I can run $(HOST_ARCH)-nm in the
>   build. This works. But I discovered that I don't even need to do that:
>   it looks like the vanilla "nm" from binutils:amd64 is able to operate
>   on arm64 binaries. Is this something that can be relied on? Do I need
>   to bother with binutils-for-host and $(HOST_ARCH)-nm? Am I confused?

I am also under the impression that some of the binutils are
architecture-generic. I'm not sure whether nm is one of them. You don't
actually need to depend on binutils-for-*, because it is considered
build-essential (even for cross builds). So if bare "nm" works, then
that's probably good enough?

> - llvm-objcopy lives in the llvm package. There's no llvm-for-host or
>   $(HOST_ARCH)-llvm-objcopy, so I don't know how to make this work. Does
>   anybody have ideas?

I guess the llvm package should eventually become Multi-Arch: allowed.
In the mean time, you may Build-Depends: llvm:native. Since llvm is
multi-target, you need to explicitly tell it about the desired target
for each invocation. Unlike gcc where this is done by choosing the
executable name, for llvm-objcopy you get to pass --target and
unfortunately the thing you put there is not provided by
dpkg-architecture, so you get to do some kind of translation layer.

This raises the question whether we would want to centralize these
architecture aspects into some piece inside dpkg. There also is
DEB_HOST_RUST_TYPE computed by some makefile from the rust toolchain and
I guess we also want such a variable for LLVM maintained centrally. I'm
open to suggestions.

> I haven't found a better way to do this. Suggestions?

No idea.

Helmut