Bug#1085853: libclang-rt-19-dev: please re-enable for 32-bit archs

[Michael Tokarev]

On Tue, 22 Oct 2024 19:01:02 -0400 Andres Salomon <dilinger at queued.net> wrote:
> Package: libclang-rt-19-dev
> Version: 1:19.1.2-1
> 
> libclang-rt-19-dev currently isn't built for armhf, which is keeping 
> chromium (which recently switched away from clang 16) from migrating to 
> trixie. When I asked on IRC about why it wasn't built for armhf, I was 
> pointed to this commit, where libclang-rt-*dev stops being built for 
> 32-bit architectures:
> 
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/1a18aa1aa6e9fc698868fd22a99ea875f3efb20a
> 
> This was originally added to fix clang 18 FTBFS. The workaround has 
> since been removed from the 18 branch, but that hasn't been merged into 
> the 19 branch. I'd appreciate if someone could merge the removal into 
> the 19 branch so chromium's build-deps on armhf can be satisfied.

Please note: this is a bit more tricky that can be immediately seen
when considering backportin of llvm19 to bookworm.  It is not a prob
just to (re-)enable this on trixie alone.

Namely, it needs a "t32 transition" when going from trixie to bookworm.

The problem is: current libllvm19 et al on trixie uses 64bit time_t
on 32bit platforms like armhf (I omit the i386 case here for brevity).
But when rebuilding this on bookworm, it'll use 32bit time_t.

Next, when one installs such libllvm19[-dev] with 32bit time_t on
bookworm system and builds something with it, it will use libllvm19
with 32bit time_t interface.

Now, when upgrading such system from bookworm to trixie, it will get
libllvm19 with 64bit time_t, which is incompatible with the programs
built on bookworm with 32bit time_t libllvm19.

So either current libllvm19 on trixie should have t64 suffix and this
suffix should be dropped when doing the backport; or when doing the
backport, all affected libs should have t32 suffix (and there's no
provision from dpkg to support ${t32:Provides}); or we just omit
the affected 32bit architectures such as armel.

It is definitely not enough to re-enable building stuff on 32bit
platforms to have the resulting package backportable.

Maybe it can be done by adding the t64 suffix to *current* libllvm19
et all on trixie *before* considering further actions, if we're to
think about back-porting it to bookworm.

Thanks,

/mjt