Passing on a request from the developers of the FEX x86 emulator:

While building mixed-architecture software, they've been frustrated by
the fact that files in /usr/lib/llvm-19 are not multi-arch
co-installable, so on Debian/Ubuntu they can't build amd64 and i386 code
that uses libLLVM (such as 64- and 32-bit versions of Mesa) without
entering separate containers/chroots.

This affects llvm-{19,20}-dev and perhaps others.

I'm told that on other distributions like the Red Hat and Arch families,
the equivalent of our /usr/lib/llvm-19 is something like
/usr/lib{64,}/llvm (Red Hat) or /usr/lib{,32}/llvm (Arch). This suggests
that on Debian, it should be possible to use our equivalent of lib64,
/usr/lib/${DEB_HOST_MULTIARCH}/llvm-{19,20,...}, for a similar level of
co-installability.

Thanks,
    smcv

Control: clone -1 -2 -3
Control: retitle -2 llvm-toolchain-21: please move /usr/lib/llvm* to a multi-arch co-installable location
Control: reassign -2 src:llvm-toolchain-21
Control: retitle -3 llvm-toolchain-snapshot: please move /usr/lib/llvm* to a multi-arch co-installable location
Control: reassign -3 src:llvm-toolchain-snapshot
Control: block -2 by 1101291
Control: block 1111183 by 1116199
Control: block -3 by 1116200

This applies equally to the -21 and -22 branches of LLVM.

As I mentioned on #1101291 and its clones, I think it would be best if
the RC bug (#1101291 and its clones) was resolved before making any
attempt to do this.

After that, I think perhaps the best approach to resolving this wishlist
request would probably be to choose a cutoff version of LLVM that is
newer than the default (perhaps 20 or 21), make this change in that
branch and all newer branches, and mark the request wontfix for all
older branches. That way, any regressions can be dealt with before the
changed version becomes the new default.

I believe a solution could look something like this:

1. In debian/rules, configure with something like
    -DCMAKE_INSTALL_PREFIX=/usr/lib/$(DEB_HOST_MULTIARCH)/llvm-$(LLVM_VERSION)
    instead of the current
    -DCMAKE_INSTALL_PREFIX=/usr/lib/llvm-$(LLVM_VERSION)

2. In the rest of the packaging (especially .install files), wherever
    it previously used /usr/lib/llvm-@VERSION@, replace with
    /usr/lib/${DEB_HOST_MULTIARCH}/llvm-@VERSION@ or
    /usr/lib/*/llvm-@VERSION@ or similar

This is similar to the way it works in, for example, Fedora (but they
use llvm@VERSION@ instead of llvm-@VERSION@, which is only a cosmetic
difference, and they use /usr/lib or /usr/lib64 instead of
/usr/lib/${DEB_HOST_MULTIARCH} because that's the closest equivalent in
their multilib design).

     smcv

I don't like the idea of moving the whole LLVM topdir
(/usr/lib/llvm-X.Y) to a new location.

As a first step, I'd like to

  - make the runtime libs M-A: same, with having the
    real files reside in /usr/lib/<multiarch> and
    removing the files in /usr/lib/llvm-X.Y.

  - What has been in /usr/lib/llvm-X.Y in the runtime
    libs packages, is moved to the corresponding -dev
    packages, symlinking the files in /usr/lib/<multiarch>.
    And adding Breaks/Replaces.

As a second step, I'd like to see, if
/usr/lib/llvm-X.Y/lib/<multiarch> can be introduced, assuming, that
needs adjustments for the upstream makefiles. Even if we move these
files around manually, the RPATH for the executables has to be adjusted.

Matthias

I don't like the idea of moving the whole LLVM topdir
(/usr/lib/llvm-X.Y) to a new location.

As a first step, I'd like to

  - make the runtime libs M-A: same, with having the
    real files reside in /usr/lib/<multiarch> and
    removing the files in /usr/lib/llvm-X.Y.

  - What has been in /usr/lib/llvm-X.Y in the runtime
    libs packages, is moved to the corresponding -dev
    packages, symlinking the files in /usr/lib/<multiarch>.
    And adding Breaks/Replaces.

As a second step, I'd like to see, if
/usr/lib/llvm-X.Y/lib/<multiarch> can be introduced, assuming, that
needs adjustments for the upstream makefiles. Even if we move these
files around manually, the RPATH for the executables has to be adjusted.

Matthias

This is also important with regards to libclang-rt-<ver>-dev, for linking with sanitizer runtimes.

What’s odd about that one is that the arch dependent files already have arch prefixes, presumably because of the wasm and windows runtimes.

I am routingly cross-compiling mesa for i386 and amd64, on amd64 system.

And by routinly I mean weekly for about 5 years.

https://gist.github.com/baryluk/1041204eff4cc4fad6f1508afe67b562

libllvmXY itself can be coinstalled.

The primary issue are header files. These cannot be easily coinstalled
indeed.

However, I found that header files are actually all the same really, and
anything specific to arch is in the headers changed conditionally.

So installing libllvm-XY-dev:amd64 and then pointing i386 to use them
anyway works.

$ dpkg -l|grep -E 'llvm-21|llvm21'
ii  libllvm21:amd64                                          1:21.1.8-1                                amd64        Modular compiler and toolchain technologies, runtime library
ii  libllvm21:i386                                           1:21.1.8-1                                i386         Modular compiler and toolchain technologies, runtime library
ii  libllvm21-dbgsym:amd64                                   1:21.1.8-1                                amd64        debug symbols for libllvm21
ii  libllvm21-dbgsym:i386                                    1:21.1.8-1                                i386         debug symbols for libllvm21
ii  llvm-21                                                  1:21.1.8-1                                amd64        Modular compiler and toolchain technologies
ii  llvm-21-dev                                              1:21.1.8-1                                amd64        Modular compiler and toolchain technologies, libraries and headers
ii  llvm-21-linker-tools                                     1:21.1.8-1                                amd64        Modular compiler and toolchain technologies - Plugins
ii  llvm-21-runtime                                          1:21.1.8-1                                amd64        Modular compiler and toolchain technologies, IR interpreter
ii  llvm-21-tools                                            1:21.1.8-1                                amd64        Modular compiler and toolchain technologies, tools


In meson I do:

meson-cross-i386.ini:

[binaries]
c = '/usr/bin/i686-linux-gnu-gcc-{GCCVERSION}'
cpp = '/usr/bin/i686-linux-gnu-g++-{GCCVERSION}'
ar = '/usr/bin/i686-linux-gnu-gcc-ar-{GCCVERSION}'
strip = '/usr/bin/i686-linux-gnu-strip'
pkg-config = '/usr/bin/i686-linux-gnu-pkg-config'
; We are cheating here. We are using 64-bit llvm-config. But we stars align
; it should work (same compiler and linker flags will be used).
llvm-config = '/usr/bin/llvm-config-{LLVMVERSION}'
; llvm-config = '/usr/lib/llvm-{LLVMVERSION}/bin/llvm-config'
rust_ld = '/usr/bin/i686-linux-gnu-gcc-{GCCVERSION}'
rust = ['rustc', '--target', 'i686-unknown-linux-gnu']
; -C linker=gcc -C link-arg=-m32
; set BINDGEN_EXTRA_CLANG_ARGS to either --target=i686-unknown-linux-gnu or -target i686-unknown-linux-gnu

[built-in options]
c_args = ['-m32']
c_link_args = ['-m32']
cpp_args = ['-m32']
cpp_link_args = ['-m32']

[host_machine]
system = 'linux'
cpu_family = 'x86'
cpu = 'i686'
endian = 'little'


While this is little hacky - I am using 64-bit llvm-config, but because
it gives same results as 32-bit one, it kind of just works, and I had no
issues ever with this (yet) for years.

Give it a try. No need for containers or chroots.

However, I do agree, that having the -dev packages coinstallable, either
by marking them `Multi-Arch :same` (if possible), or in separate
location, would be nice.

It would be also desirable to put llvm-config and be able to call
different arch ones easily (if it is some script it should just work
modulo some variable changes, alternativly running it via qemu binfmt
handler). I belive I did open a bug about llvm-config and multi-arch
few years ago, but I cannot find it now.


Regards,
Witold