On Tue, Oct 11, 2022 at 4:06 AM karogyoker999 <karogyok...@gmail.com> wrote: > > > As far as I see your MR just adds a dependency to sse2-support, > > which I guess just makes the installation abort in case of a CPU > > not supporting sse2, so I guess this would just make > > mesa not installable on your hardware? > > Exactly. > > It will abort the installation as it wouldn't work anyways. > Mesa now requires SSE2 and therefore Xorg as well. > The workaround is to use Wayland with GNOME or KDE. > But KDE requires SSE2 since several months too (and therefore fails to > install). > It is better to have the installation fail rather than > having an unusable system after install. Because in the latter case, > it would mean that users would be disappointed, much time would be wasted > to troubleshoot. Failing the installation with a clear error message > is a much better solution.
This is a bit of a further pain point for those out there running on P6 systems as they commonly have video hardware that only supports DRI1. > The alternative would be to disable SSE2 for all i386 packages of libz3-4. > But usually maintainers don't like that since that would have a performance > impact on Pentium 4 CPUs. So there is a choice to make: disable SSE2 on > all x86_32 CPUs or fail the install on everything except Pentium 4. According to the developers of libz4-3, the precision of the FPU x87 registers is not sufficient therefore a libz4-3 package compiled without SSE2 would be non-functional. It would be far better if libz3-4 could fail late rather than early. If it could fail later, in the case that calls to libz3-4 were made I think that would avoid the current issue. Perhaps if video hardware that requires shader compilation isn't present, no failures would occur. However the crash occurs at dlopen time as there are a number of c++ static initializers that get executed so even if no calls to libz3-4 are even made, or even calls to the mesa library that links to libllvm14, which links to libz3-4, everything works fine. I'm not even certain that libz3-4 is ever even called by mesa. I think it's just an option feature of libllvm and because mesa links libllvm, it ends up calling dlopen on the libz3-4 library. The debian changelog reads: * Enable Z3 solver (llvm & clang) to improve the quality of the static analysis results This doesn't sound like a feature mesa needs and I can't find any mention of mesa using the z3 solver. > There is a Debian patch [1] for the z3 package which does something with SSE2. > But then why is it still crashing? Maybe z3 has some hardcoded SSE2 > instruction somewhere? > Or it has been just compiled with the incorrect compiler flags? Doesn't appear to be disabling SSE2, just trying to make something work when SSE2 is disabled. Not sure why. > To have both performance and compatibility, a runtime check would be needed > to be added, but that would mean a significant amount of work. > > Until this work is not done by someone, failing the installation is > still better than > crashing and leaving the system in an unbootable state. > > [1]: https://sources.debian.org/patches/z3/4.8.12-1/00-intrinsics.patch/ The package pulling in libz3-4 into the dependency chain is libllvm14. I've noticed the ubuntu version of the package does not link against libz3-4 and the libz3-4 package can be removed from the system and xorg and mesa function just fine. Perhaps a version of libllvm14 compiled without libz3-4 support that could be installed on instead or even along side?