Bug#1140755: clang-21: Uninstallable for cross builds

[Helmut Grohne]

Control: tags -1 - patch

Hi Yavor,

On Fri, Jun 26, 2026 at 12:30:08AM +0300, Yavor Doganov wrote:
> Package: clang-21
> Version: 1:21.1.8-7+b3
> Tags: patch
> User: debian-cross at lists.debian.org
> Usertags: cross-satisfiability

Thanks for addressing the wider audience for review.

> Packages that build-depend on clang cannot be cross built because
> bin:clang from src:llvm-defaults depends on bin:clang-$MAJORVER which
> in turn depends on binutils.  I used the attached patch to build
> llvm-toolchain-21 on arm64/s390x.  Then I used the produced binary
> packages and successfully cross built (on amd64 for arm64/s390x) a
> bunch of packages that build-depend on clang, including the package
> I'm interested in, libobjc2 (not yet in Debian).

I agree that there is a problem here, but the problem I see is a bit
bigger than what you describe.

> We at the GNUstep team plan to package the GNUstep Objective-C runtime
> which was specifically written for Clang, and to provide dual runtime
> support on architectures where it will be available.  We've spent
> considerable efforts to make the GNUstep stack cross-buildable during
> the trixie release cycle and it would be a pity to lose that feature.

Awesome. It's been a while that I ran into a GNUstep-related cross build
failure. Now I understand why.

It seems like your development packages declare a (runtime) dependency
on a clang package. This is unusual at best. Normally, libraries do not
depend on a toolchain. Can you give some background on why you think
this is needed?

You rightly indicate that your dependencies cannot use :native. Given
your patch, I expect that what you end up with is a host architecture
clang. This is not something you can actually run during a cross build.
While your dependencies may become satisfiable, your build fails upon
the first attempt to run the compiler. If it succeeds, you like
installed qemu-user-binfmt on the machine, but you cannot rely on that.

When clang links something, it runs /usr/bin/ld. This is not something
that binutils-for-host provides. Your patch breaks the very simple use
case of natively building and linking a hello world C source file using
clang. I would hope that clang's autopkgtests readily fail once your
patch is applied. Did you run them?

I am not sure where we want to go from here. clang is a multi-target
compiler, but it uses single-target binutils underneath. If you pass
-target, it calls out to prefixed binutils, so technically speaking we'd
need clang to depend on binutils-for-host for all architectures at the
same time (or use binutils-multiarch). Having clang depend on
binutils-multiarch may not be the worst of options. If we don't want
that, we likely need a clang-for-host package that can forward the
architecture constraint to the underlying binutils-for-host package.

If you look at cross build systems involving gcc, many of them have
learned that you can do a cross build by varying the compiler
executable. This approach would technically also work for clang as it
can parse its argv[0] and derive a target triplet from that. I'm not
sure that this is how many projects use clang. The other way is passing
a -target. How many projects reliably pass that? Which of these
approaches do we want to label the preferred approach?

I fear I'm adding more questions than answers.

Helmut