On Thu, 13 Feb 2025 at 14:55:14 +0100, Fabian Grünbichler wrote:
> On Thu, Feb 13, 2025 at 12:35:51PM +0100, Matthias Klose wrote:
> > alternatives could also include to retire the i386 port
I think removing i386 completely would be doing our users a disservice:
that would mean our amd64 users lose the ability to run 32-bit Wine, as
well as legacy 32-bit Linux binaries (most commonly game-related). In
my view an i386 port that is not optimally fast, or that is not
feature-complete, would be preferable to no i386 port at all.
I notice in particular that in Ubuntu, where the i386 port has been
cut down to the minimum of packages required for these legacy-binary
use-cases, significant effort has gone into cutting down packages'
dependencies so that they can still be built on i386, suggesting that
Ubuntu also values the existence of backward compatibility with legacy
binaries.
Similarly, our colleagues in distros that don't have the advantage
of multiarch have generally found that they need to keep at least a
subset of libraries available via multilib: for example the Fedora/Red
Hat ecosystem still has i686 RPMs, Arch has the lib32- family of packages,
and even intentionally unusual distros like NixOS have their equivalent.
I personally think an i386 port that is a multiarch foreign architecture,
either a nearly-full one like in Debian or a small subset like in Ubuntu,
would be a much less painful way to achieve this than expanding the
coverage of multilib.
I don't really want to have to remove Rust code from i386 because
that would itself be a rather large transition. For example, librsvg
alone has around 250 direct rdeps, which would need either removal or
sourceful changes; one of those is that if we want to keep 32-bit libwine
(which I believe we do), then we cannot remove libavcodec from i386, and
instead we would have to make sourceful changes to disable its optional
librsvg support.
But, if it comes down to "remove all Rust code from i386, or remove i386"
then I think removing Rust code from i386 would be a painfully large
amount of work, but still the less damaging option.
> The issue is unfortunately not that [Rust code] might not run on some hardware
> (that would be the case if we were to selectively violate the baseline
> by bumping it in rustc/LLVM while still pretending Debian's i386
> baseline doesn't require SSE2/MMX, which nobody is suggesting!), but
> that they are miscompiled and then segfault (depending on execution
> path, so hard to catch until people run into it) both on hardware that
> supports and hardware that doesn't support SSE2.
If raising the baseline in general is ruled out, then I actually think
selectively violating the baseline in rustc/LLVM would be a less damaging
option than removing all Rust code from i386.
The options as I see them, *including* the options that I would personally
prefer to rule out, are:
- Status quo: don't change anything. As Fabian says, Rust code on i386
will sometimes be miscompiled and might crash.
- Raise baseline to i686+SSE2+MMX and make gcc require/assume this
- Raise "official" baseline to i686+SSE2+MMX, leave gcc producing
code that would have worked with the previous baseline by default,
but rustc/LLVM may require/assume i686+SSE2+MMX
- Officially keep current baseline, intentionally violate the baseline in
rustc (and maybe LLVM?) so that rustc produces working code, and
have the release team announce that the resulting baseline violations
are not to be considered RC bugs
- Do a transition to remove all Rust code from i386
- Remove i386 completely, re-introduce the equivalent of ia32-libs so we
can still provide 32-bit Wine and Mesa
(I'm mentioning this for completeness but I suspect the release team
would veto this, because nobody liked ia32-libs)
- Remove i386 completely, no more 32-bit Wine, no more ability to
install Steam, etc.
Does anyone see others?
smcv
