Helmut Grohne wrote: > On Fri, Jun 26, 2026 at 12:30:08AM +0300, Yavor Doganov wrote: > > 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 agree that there is a problem here, but the problem I see is a bit > bigger than what you describe.
I knew it was not that simple... > > 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. There's still #1094879; simpleagenda.app has exactly the same problem. I recently fixed gnustep-sqlclient and edenmath.app (regression). > 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? The most important reason is that occasionally we have to enforce a non-default compiler for all GNUstep packages and it's easier to control it from one package instead of doing sourceful uploads for ~60 packages. TBH, the last time we did this was 15 years ago with GCC 4.7 and its libobjc transition. But it's likely to occur much more often with clang: libobjc2 supports only a subset of architectures where clang is available, because one function is implemented in assembly. Adding support for more architectures is "simply" adding an implementation in assembly for a new architecture. So suppose all GNUstep packages have this in their Build-Depends field: clang:native [amd64 arm64 armhf hurd-any i386 riscv64], libobjc2-dev [amd64 arm64 armhf hurd-any i386 riscv64], If an implementation for loong64 is added, it would require correction in debian/control for all packages and sourceful uploads in the right order. That's rather inconvenient. Another reason is that a lot of users requested to make it easy to get a capable development environment by installing just one package (gnustep-devel or gnustep-core-devel). > 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. That's indeed the case -- I had qemu-user-binfmt installed and that's what confused me. Removing it immediately shows the problem. And I can't explain why, but now I can reliably reproduce #1094879 which would allow me to work on a fix that can be included upstream. > 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. Of course you are right, that's so blatantly obvious. > I would hope that clang's autopkgtests readily fail once your patch > is applied. Did you run them? Sadly, no; mea culpa. > 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. Perhaps I'm misunderstanding something, but binutils-multiarch depends on binutils, which would lead to the same problem we have now. > 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 guess all of these are questions for the LLVM maintainers.
