Broken Software

This page lists software that is known not to work correctly on Apple Silicon machines. We publish it in the hope that it incentivizes inclined members of the community to contribute fixes for the affected packages upstream, bettering the AArch64 software ecosystem for everyone.

This is almost always due to incorrect/incomplete support for 16K pages. Packages are sometimes built assuming a 4K page size, or are otherwise incompatible with large pages. This has not been a serious issue for desktop Linux software, as x86/amd64 supports only 4K pages and PowerPC supports only 4K or 64K pages. AArch64 is unique in that an AArch64 machine can use 4K, 16K or 64K pages.

While these machines can boot 4K kernels, doing so requires some very hacky patches, as the IOMMUs only support 16K-aligned pages. Not only does this cause severe performance penalties, but it does not address the actual problem which is userspace software with incomplete support for AArch64. XNU (macOS) gets around this by supporting independent page sizes in userspace, however we have no such mechanism in Linux and likely never will.

Desktop-class AArch64 machines are only going to become more common in the next few years. By having an upstream-first policy we can make sure these fixes are propagated to everyone via distro repositories, improving the AArch64 ecosystem for everyone! See Fixed packages for a list of software that has been fixed for everyone as a result of this. You wouldn’t want us to keep Emacs all to ourselves now, would you?

If an ELF executable or library has sections which are not aligned to 16K pages, the loader will be unable to map the binary into memory and will signal this failure by causing a segmentation fault before the program even technically starts execution.

You can confirm that this is the case using readelf -l /path/to/binary. All program header sections of type LOAD must have an ALIGN value of at least 0x4000 to successfully load on a 16K machine like Apple Silicon. The library illustrated here is only aligned for 4K pages (0x1000) so it cannot load.

$ readelf -l lib64/ld-android.so

Elf file type is DYN (Shared object file)
Entry point 0x0
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                 0x00000000000001f8 0x00000000000001f8  R      0x8
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000874 0x0000000000000874  R      0x1000
  LOAD           0x0000000000001000 0x0000000000001000 0x0000000000001000
                 0x0000000000000004 0x0000000000000004  R E    0x1000
  LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000
                 0x00000000000000a0 0x00000000000000a0  RW     0x1000
  DYNAMIC        0x0000000000002000 0x0000000000002000 0x0000000000002000
                 0x00000000000000a0 0x00000000000000a0  RW     0x8
  GNU_RELRO      0x0000000000002000 0x0000000000002000 0x0000000000002000
                 0x00000000000000a0 0x0000000000001000  R      0x1
  GNU_EH_FRAME   0x000000000000082c 0x000000000000082c 0x000000000000082c
                 0x0000000000000014 0x0000000000000014  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x0
  NOTE           0x0000000000000238 0x0000000000000238 0x0000000000000238
                 0x0000000000000020 0x0000000000000020  R      0x4

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .note.gnu.build-id .dynsym .gnu.hash .dynstr .eh_frame_hdr .eh_frame 
   02     .text 
   03     .dynamic 
   04     .dynamic 
   05     .dynamic 
   06     .eh_frame_hdr 
   07     
   08     .note.gnu.build-id 

Though the default for AArch64 compilers is to produce ELF files with sections aligned to 64K for compatibility with all AArch64 machines, tooling bugs (such as binaries manipulated by old versions of patchelf) or customized compiler flags (such as many Google programs, including older versions of Chrome (and Electron) and most current Android programs) may result in a binary whose sections are only aligned to 4K.

* In the future, running x86-64 software will be supported via a 4k page size microVM running FEX.

Open issues (other than page size issues) in third-party software, reported and/or tracked by Asahi core team members: