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: [email protected] > 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
