On Wed, Jun 25, 2025 at 09:14:20PM +0100, Jonathan Wakely wrote: > On Wed, 25 Jun 2025 at 20:55, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > On Wed, Jun 25, 2025 at 08:45:33PM +0100, Jonathan Wakely wrote: > > > On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote: > > > > > > > > And there is another aspect, Fedora being used often as a distribution > > > > used > > > > by developers working on compilers and other parts of toolchain. Not > > > > having > > > > at least basic 32-bit libraries will be a major blocker. And not just > > > > for > > > > GCC/LLVM/GDB etc. developers, but also for people working on other > > > > compilers > > > > like EDG that raised concerns about this proposal and there could be > > > > many > > > > users migrating away from Fedora which no longer provides what the users > > > > need. > > > > > > Yes, it would be a pretty big problem if the Fedora packagers of gcc, > > > gdb etc. (who are among the most active contributors to the upstream > > > projects) were unable to use Fedora for that upstream development. > > > > Fedora ships just a handful of host architectures, out of the many that > > GCC, binutils, etc support, so this surely isn't a new / unique problem > > to i386 ? > > Of the "primary platforms" that GCC supports (see > https://gcc.gnu.org/gcc-15/criteria.html for the current list) Fedora > supports more than half of them. And for freebsd and solaris, that's > somebody else's problem :-) > > I can use power systems (running Fedora or RHEL) to test on power, and > aarch64 systems (running Fedora or RHEL) to test on aarch64, but to > test i686 I use x86_64 with -m32, and I don't think I'm alone in that, > I know Jakub does too. I don't have access to any *real* x86-32 > systems, but that's OK because almost all the time testing on x86-64 > with -m32 works exactly the same as an i686 kernel+userspace. > > For my work (libstdc++) the differences between power64le-linux and > x86_64-linux are minor, it's far more common to have portability > problems between 64-bit and 32-bit, and that's why doing regular > testing with -m32 is so useful for me. The ability to do that on > Fedora is extremely valuable for maintaining the C++ runtime.
Yes, I can understand the benefit of testing 64 vs 32 bit in general, as that's a frequent source of bugs in many apps still, alongside big endian vs little endian, which s390x gives coverage of. Would containers mitigate this use case well enough ? For most upstream projects I'm invovled in, we've got Debian containers of every arch except x86_64, with the full suite of cross compilers and all libraries required, so we can do all build testing from a x86_64 Fedora host regardless of arch. Actually running binaries of non x86 arches, needs qemu-user though, and that's not foolproof in its emulation. > > Fedora does ship gcc/bintuils cross-compiler builds for all the other > > target arches already, so presumably i386 could join that collection ? > > Would that be sufficient for the kernel / firmware -m32 needs ? > > For the kernel, maybe, but for the toolchain we also need glibc, and a > handful of libs (zlibng, zstd, gmp, mpfr, mpc). It's much, much less > than the whole distro though. I think using ExcludeArch i686 for the > majority of packages makes a lot of sense. It is a shame RPM doesn't have "IncludeArch", as that could avoid bulk modifying many 1000's of RPM specs, which isn't entirely trivial when some will already have a mix of ExcludeArch and ExclusiveArch. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
