Bug#990994: llvm-12-tools cannot be installed for a foreign architecture

[Helmut Grohne]

Hi,

Christoph asked me to comment on this.

On Fri, Sep 17, 2021 at 03:43:21PM +0200, Sylvestre Ledru wrote:
> Hello,
> 
> Le 17/09/2021 à 15:28, Christoph Berg a écrit :
> > Re: Michel Dänzer
> > > Package: llvm-12-tools
> > > Version: 1:12.0.1~+rc4-1
> > > Severity: normal
> > > 
> > > llvm-12-tools requires python3 packages from the same architecture. This prevents installing llvm-12-tools (and by extension llvm-12-dev) for a foreign architecture.
> > > 
> > > E.g. trying to install llvm-12-tools:i386 with aptitude gives:
> > > 
> > >   llvm-12-tools:i386 : Depends: python3:i386 but it is not going to be installed
> > >                        Depends: python3-yaml:i386 but it is not going to be installed
> > > 
> > > See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833/diffs?commit_id=af0fde955c518447ccd92134517b4e69308e10b2#3f46a9fa9651371b76f0894b75d719a4c5659642_44_45 for how I had to work around this in Mesa's upstream CI.

I confirm that it is not possible to install llvm-12-tools for a foreign
architecture in unstable.

> > > (In buster it was still possible to install llvm-*-dev packages for foreign architectures)

I confirm. The change that made a difference here is that llvm-V-dev now
depends on llvm-N-tools while it didn't do that in buster. llvm-V-tools
was never installable for foreign architectures.

> > The fix for this question is "Depends: python3:any" I believe.

Unfortunately, it's not that easy. There also is python3-pygments and
python3-yaml. Luckily, python3-pygments is already M-A:foreign.
python3-yaml however is M-A:allowed. So if you go this route, it'll be:

    Depends: python3:any, python3-pygments, python3-yaml:any

That totally leaves open the question of whether that change is correct.
It merely states that the originally proposed change is insufficient.

> > Different take on a related issue:
> > 
> > When cross-compiling, I cannot install clang-11 and llvm-11-dev for
> > the build-architecture when installing the host-architecture
> > postgresql-server-dev-13. I think the fix is annotating (some subset
> > of) the llvm packges with "Multi-Arch: allowed".

I'm afraid I didn't notice this in time for the bullseye release. Cross
building with clang on bullseye is quite simply broken it seems.

Please refrain from adding "M-A:allowed" without thought. It is a
heavy-handed sword. Think of it like adding an epoch. Consulting d-devel
or at least a multiarch expert would be good as it is very difficult to
revert M-A:allowed in case it turns out to be wrong.

> > Please consider applying these fixes so clang can be used for
> > cross-compilation.

I fear what needs to be fixed is quite non-obvious.

> If you folks want to see progress on this, I would need help. ( https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/tree/12/debian )
> I don't know how to test that properly (so, testcase which aren't rebuild postgresql would be appredciated)
> and I made too many mistakes in the past with
> the multi-arch flag to trust myself :)

I concur that adding a test case would help a lot. It would be even
better if that could be an autopkgtest, but I'm unsure whether we can
mix architectures in autopkgtests like that. Failing that, maybe
something based on mmdebstrap could do it.

Thus far, much of my reply was about explaining why the proposed
solutions don't work. That's not very constructive. So I have two things
to say to actually improve the situation.

First and foremost, llvm is very broken when it comes to multiarch. It
has a lot of M-A:same annotations that factually are lies. They've been
reported by the multiarch hinter for quite a long while:

    libc++-12-dev conflicts on 3 files starting with /usr/lib/llvm-12/lib/libc++ on any two of amd64, arm64, armel, armhf, and 5 more
    libc++1-12 conflicts on /usr/lib/llvm-12/lib/libc++.so.1.0 on any two of amd64, arm64, armel, armhf, and 5 more
    libc++abi-12-dev conflicts on /usr/lib/llvm-12/lib/libc++abi.a on any two of amd64, arm64, armel, armhf, and 5 more
    libc++abi1-12 conflicts on /usr/lib/llvm-12/lib/libc++abi.so.1.0 on any two of amd64, arm64, armel, armhf, and 5 more
    libomp5-12 conflicts on 3 files starting with /usr/lib/llvm-12/lib/libomp on any two of amd64, arm64, armhf, i386, and 2 more
    libunwind-12 conflicts on /usr/lib/llvm-12/lib/libunwind.so.1.0 on any two of amd64, arm64, armhf, i386, and 2 more
    libunwind-12-dev conflicts on /usr/lib/llvm-12/lib/libunwind.a on any two of amd64, arm64, armhf, i386, and 2 more

The above are serious issues and result in dpkg unpack errors (the least
thing you'd want). They're trivially fixed by removing Multi-Arch: same
from the mentioned packages. Please do so as soon as possible for all
llvm releases.

    clang-12-doc could be marked Multi-Arch: foreign
    llvm-12-doc could be marked Multi-Arch: foreign

These two are quite simple fixes that don't have a big impact, but you
can easily include them.

    clang-12-examples could be converted to Architecture: all and marked Multi-Arch: foreign
    libomp-12-doc could be converted to Architecture: all and marked Multi-Arch: foreign

Here, two of your packages are unnecessarily architecture-dependent.
Fixing these requires a little more care (e.g. with --linkdoc), but
changing them to Architecture: all is a general improvement. Again the
impact is likely low.

    libclang-cpp12-dev could be marked Multi-Arch: same

Low impact. I don't quite understand why this -dev package completely
lacks development headers. That sounds wrong.

    liblld-12-dev could be marked Multi-Arch: same

This is fishy again. This package seems to be header-only except that it
also Depends: liblld-12. Looking into liblld-12 one can see that it only
contains static libraries, not shared ones. That totally doesn't make
any sense. I propose merging the content of liblld-12 into
liblld-12-dev. For backwards-compatibility, liblld-12-dev can Provides:
liblld-12 if needed. Until this is done, please ignore the hint.

    python3-clang-12 could be marked Multi-Arch: same

This is also fishy. Usually, the multiarch hinter does not issue
M-A:same annotations for python modules, because they perform byte
compilation using a maintainer script. Evidently, python3-clang-12 does
not include the relevant maintainer script and thus does not perform
byte compilation. I ignore the hint until you solved this problem.

Moreover, python3-clang-12 only contains .py files, so it looks as if it
is a pure python module. Usually, those are Architecture: all. I suppose
that Architecture: any is correct here. It uses ctypes to access
libraries from libclang-12-dev. Therefore it needs to employ the
"multiarch interpreter workaround", which means python3-clang-12 should
be Architecture: any, exactly as it is. Good.

That already was a lot, but it only was the low hanging fruit and none
of this will actually fix the issue reported in this bug. Yet, please go
ahead and fix the "obvious" issues first.

So the real goal is cross building using clang I guess. Please correct
me if that's wrong.

For some reason, cross building with clang requires installing the
foreign llvm-V-dev. If someone can shed light on the "why" that would be
awesome.

Now llvm-V-dev is not installable for foreign architectures since
bullseye. That's what this bug is about, right? Fixing that will require
quite some changes to how llvm packages are organized. No, it is not
adding some M-A header here and there. It really requires changing
Depends, moving files between packages and splitting packages. Not a
lightweight thing to do, so we better understand the implications well
before doing it.

I can immediately identify two problems with foreign installation of
llvm-V-dev. That's certainly not exhaustive, but each of them is a
show-stopper. It's the dependencies on llvm-V-tools and on llvm-V. The
former was already evident from the bug report. The latter is an issue,
because a foreign llvm-V-dev will pull a foreign llvm-V, which contains
all the /usr/bin/llvm-*-V tools for a foreign architecture and we'll be
unable to run them. So it might become installable, but in a useless
way.

For llvm-V-tools the installability issue becomes evident from the
python dependencies. I guess that they're there for opt-viewer. So I
wonder whether opt-viewer could be split out to a separate package
(together with those unsatisfiable dependencies). Then maybe
llvm-V-tools can recommend opt-viewer instead of depending on them? I'm
not sure how central the functionality is to llvm, but recommends are
typically skipped for (package) building.

Admittedly, I've only scratched the surface of issues here. That's a
longish list of proposed changes though.

Beyond this, serious use of llvm in cross architecture setting will
require adding pkg-config files. That's reported as #897275.

Given the length of this mail, I guess nobody makes it to the end. I can
write arbitrary nonsense here and nobody will notice.

Helmut