* Neal Gompa: > On Fri, Aug 20, 2021 at 12:45 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >> * Neal Gompa: >> >> > On Thu, Aug 19, 2021 at 8:59 AM Dennis Gilmore <dennis@xxxxxxxx> wrote: >> >> >> >> On Wed, Aug 18, 2021 at 3:11 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >> > >> >> > * Dennis Gilmore: >> >> > >> >> > > We intentionally never looked at enabling that and always had no plans >> >> > > to support multi-lib on Arm >> >> > >> >> > It's not multilib. Buildroots aren't multilib. >> >> > >> >> > I'm pretty sure no one but Fedora is building 32-bit Arm binaries on >> >> > 32-bit Arm kernels. It's very much a dead end. >> >> > >> >> > Debian uses 64-bit kernels: >> >> > >> >> > | Package: glibc >> >> > | Version: 2.31-16 >> >> > | Source Version: 2.31-16 >> >> > | Distribution: sid >> >> > | Machine Architecture: arm64 >> >> > | Host Architecture: armhf >> >> > | Build Architecture: armhf >> >> > | Build Type: any >> >> >> >> There is some magic that's needed for multi-lib that will be needed >> >> for the AArch64 host's rpm to install the rpms into a 32bit chroot. >> > >> > There is no "magic" other than qemu-user-static needing to be >> > installed. Mock will transparently handle everything just fine. It's >> > how I build foreign architecture packages on my computer. >> >> No, the code would run natively, without QEMU, like i686 on an x86-64 >> kernel. There is no emulation. > > That depends on the CPU. As Dennis and Peter like to remind me, > armv7hl backwards compatibility is *optional* in AArch64 CPUs (which > was really a stupid idea, but whatever). There are several AArch64 > CPUs that lack it. Maybe we're lucky and ours have it like the RPi CPU > does, but not all do. My AMD Opteron A1000 board doesn't, for example. Fedora can choose builder hardware that has native userspace support for 32-bit programs. Today, this requirement is much easier to meet than 32-bit support in supervisor mode, particularly for hardware that one can reasonably install in a data center. Jeremy Linton already said as much on this thread: | OS wise, 32-bit containers/etc work fine on 64-bit fedora | kernels. This also solves the problem that server grade HW with 32-bit | guest (EL1+) support is becoming rarer (basically only older A72 based | platforms now) and would provide a path forward on more recent | Gravaton2, Ampere, etc platforms. Also see the table on page 3 of <https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Cortex-A%20R%20M%20datasheets/Arm%20Cortex-A%20Comparison%20Table_v4.pdf>. It says “AArch32 at EL0 only” for all the newer cores. With a 64-bit kernel, we would haven't use LPAE mode either, which I assume is a an outlier and otherwise rarely used with 32-bit Arm kernels. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
