NAME

pakfire-architectures - The architectures that Pakfire knows

DESCRIPTION

Pakfire installs and builds packages for the following architectures:

Name Platform Machine Libraries

x86_64

x86

x86_64-VENDOR-linux-gnu

/usr/lib64

aarch64

arm

aarch64-VENDOR-linux-gnu

/usr/lib64

riscv64

riscv

riscv64-VENDOR-linux-gnu

/usr/lib64

loongarch64

loongarch

loongarch64-VENDOR-linux-gnu

/usr/lib64

All of them are 64 bit and little endian.

Packages that have nothing in them which depends on the architecture are noarch and can be installed everywhere. Source packages are src.

Name

What the architecture is called in the names of packages, in repositories, and what is being passed with --arch=. A makefile finds it in %{DISTRO_ARCH}.

Platform

What a couple of architectures have in common. A makefile finds it in %{DISTRO_PLATFORM}.

Machine

What the toolchain calls the system that it builds for (--host= and --build=). The vendor is the one that the configuration of the distribution has, in lower case. A makefile finds it in %{DISTRO_MACHINE}.

Libraries

Where libraries are being installed to (%{libdir}).

WHAT CAN BE BUILT WHERE

A system can always build for its own architecture.

It can also build for any other architecture of the list above if there is an emulator for it, like qemu-user. Pakfire looks for emulators that have been registered with the kernel (/proc/sys/fs/binfmt_misc). If there is one for the architecture that is being asked for, it is being made available inside the build environment, and everything that is being run in there is being run by the emulator. Nothing needs to be configured, but this is a lot slower than building on the real thing.

Without an emulator, asking for another architecture fails with "Unsupported architecture".

Compilers are never being asked to build for anything but the system that they run on. There is no cross-compilation.

WHAT IS DIFFERENT

Most of Pakfire does not care about the architecture. This is where it does:

Compiler flags

x86_64 is being built for x86-64-v2 with Control-flow Enforcement (-fcf-protection=full), and aarch64 with branch protection (-mbranch-protection=standard). The others have no flags of their own.

Checks of what has been built

Programs and libraries say whether they have been built with what the flags above enable: Indirect Branch Tracking and Shadow Stack on x86_64, and Branch Target Identification and Pointer Authentication on aarch64. Pakfire reads that when it checks a package and warns about every program and library that does not have all of them, which includes those that do not say anything at all. These are warnings and do not fail a build: an object only has this if all of the code that it has been linked from has it, and not everything can be built that way. There is nothing like this on riscv64 and loongarch64.
A package can have objects for any other machine in it (firmware, for example). Those are not being looked at for any of this.

Images

OCI images use the names that the rest of that world uses: amd64, arm64, riscv64 and loong64.

System calls

Inside the build environment, programs that use the system calls of another ABI than the one of the architecture (32 bit programs on x86_64, for example) are being killed. See pakfire-jail(7).

ADDING AN ARCHITECTURE

All architectures are listed in enum pakfire_arch in src/pakfire/arch.h. Whatever is different between them is being decided in a switch statement that names every one of them, so that after adding a new one there, Pakfire does not compile until all of the following have been taken care of:

  • Its name, its platform, and the beginning of an ELF object of that architecture (which is what emulators are being found by) in src/pakfire/arch.c.

  • Its name in the OCI world in src/pakfire/oci.c.

  • What can be checked in what has been built for it in src/pakfire/elf.c.

The compiler cannot tell about these:

  • Which ELF machine the architecture is (pakfire_elf_arch() in src/pakfire/elf.c).

  • Where its libraries are in macros/arch.macro, and its compiler flags in macros/cflags.macro if it has any.

  • The libraries that Pakfire depends on have to know it, most of all libsolv (which decides what can be installed) and libseccomp (which filters system calls inside the build environment).

SEE ALSO

pakfire(8), pakfire-jail(7)

AUTHORS

Michael Tremer