Drop clang32

[MehdiChinoune]

It has no use.

[ognevny]

@mati865 issues with i686-pc-windows-gnullvm will be solved after this PR!

[Biswa96]

OK from me. But I would like to wait for all others opinion too.

[mati865]

@mati865 issues with i686-pc-windows-gnullvm will be solved after this PR!

I don't see how it's correlated.

[ognevny]

no clang32, no need to solve it in this repo

[mati865]

And what's the problem?

[ognevny]

And what's the problem?

compile error from #21902 (comment)

[mati865]

Although we don't package them any longer, so that shouldn't be a problem, I suppose.

It won't be a problem because we don't build them on the CI.

[lazka]

Fair enough I guess.

With 32bit going away and clang32 not seeing much use it's probably not worth the effort.

I'd still prefer to create a NEWS entry for this first and phase out in chunks with a timeline. I'll have a look later.

[lazka]

I've added a NEWS entry in msys2/msys2.github.io@89521b9

and removed some packages without rdepends in 1e7737f

I am wondering if keeping a minimal toolchain/language package set around for longer would still be useful.

[MehdiChinoune]

OK to merge?

[ognevny]

@MehdiChinoune feel free to drop all reverse dependencies of Rust now (with separate commits/PRs). I will drop CLANG32 Rust in #22205

[MehdiChinoune]

Dropping rust on clang32 means practically dropping all the packages (which is the goal of this PR)

[ognevny]

Dropping rust on clang32 means practically dropping all the packages (which is the goal of this PR)

uh oh. currently there is no way to fix CLANG32 rustc, so no choice for me (I don't want to block update)

[MehdiChinoune]

I will try to rebuild some packages without extra/optional dependencies.

[MehdiChinoune]

Only remaining packages are the toochain ones.

Could we press the button and drop clang32.
Any objection?

[Biswa96]

If there is no maintenance burden, I think, the llvm toolchain should be kept for any compiler testing purposes like llvm-mingw or for mingw-w64 testing etc.

[MehdiChinoune]

If there is no maintenance burden, I think, the llvm toolchain should be kept for any compiler testing purposes like llvm-mingw or for mingw-w64 testing etc.

Isn't llvm-mingw already doing this job?
A contributor of both LLVM and mingw-w64 maintaining LLVM+mingw-w64 (llvm-mingw) for different architectures (i686, x86_64, aarch64, arm).

[mati865]

If there is no maintenance burden, I think, the llvm toolchain should be kept for any compiler testing purposes like llvm-mingw or for mingw-w64 testing etc.

It causes problems at least once a year, typically with LLVM major version upgrade. Recently it's been hitting issues with insufficient available address space for 32-bit programs.