On 2025-09-06 11:09 +0200, Helmut Grohne wrote:
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 looked at this some years ago and found that LLVM had a significant limitation in comparison to gcc from a debian point of view. LLVM has a set of built-in target ABIs, and extra knobs to adjust the output, such as ISA level, but it does not have a way to _build_ it with a set of architecture defaults that match the debian architecture base ISA+ABI. There obviously are some defaults in the package but there is no concept of the distro defaults being different from the upstream defaults. The interface in debian that we have relied on for both native and cross building is that we build gcc effectively with a default set of options so that the 'bare' invocation (for a given host triplet, or just 'gcc' on that architecture triplet) produces the correct output for the arch. So far as I could see LLVM is simply missing this mechanism. All you get to do is pass a --target (which doesn't necessarily get you output matching a debian architecture, so you have to pass other options to set an ISA baseline (at least) to make things match up to an actual arch). And as Helmut points out the names are different from GNU (debian) names, and maybe different from gcc. This was quite a few years ago, and it's possible that this functionality has been added, but probably no-one other than debian-world really relies on this interface, so I expect nothing much has changed. I think the approaches available to us are: 1) Teach llvm to take an 'architecture' name (maybe as target, probably a new option) that expands to the right set of ABI + ISA options 2) Add wrappers that do the above (which could then just be named $triplet-llvm so we could treat it just like gcc, which makes for consistent packaging) 3) Store this translation from debian arch triplet to LLVM options somewhere else (dpkg? cross-build-essential? debian LLVM package) and expect packaging to use it. There are probably wrinkles in all this to do with option ordering and what overrides what if things are inconsistent. That would need a more detailed analysis. This may mean that a simple wrapper will not actually work, and internal LLVM changes are needed. It would be great if someone decided to try and solve this. I just sort of threw up my hands a decade ago and hoped LLVM would get proper 'arch baseline/default' functionality at some point, because it would be way easier to deal with if that was done upstream. Maybe it has, maybe it hasn't. Wookey -- Principal hats: Wookware, Debian http://wookware.org/ Matrix: @wookey:matrix.org
Attachment:
signature.asc
Description: PGP signature