DeveloperWiki:Toolchain maintenance

From ArchWiki
Jump to navigation Jump to search

This page is intended to contain all relevant information to bootstrap the toolchain on Arch Linux, including any issues that are expected to be found, as well as providing documentation on the build order when new versions of important toolchain packages are released.

Build Order

For major version updated (i.e. anything other than a point release), the toolchain should be completely bootstrapped to ensure version matches across components and reproducibility. The toolchain build order is as follows:

linux-api-headers -> glibc -> binutils -> gcc -> binutils -> glibc

TODO: document the reason for this build order

Note that these builds need to be done "manually" using makechrootpkg as we want to install the build package at each step (and not clean the build root between packages). Pkgrel for the packages should be bumped to their intended final version at the beginning of this process.

Anything besides minor patch level updates (e.g. glibc-2.31 -> glibc-2.31.1), or patching individual bugs, generally do not require a full toolchain rebuild. Version bumps might trigger a full rebuild, regardless of soname bumps (e.g glibc-2.31 -> glibc-2.32).

Linux Api Headers

The linux-api-headers package, provides linux kernel headers that have been sanitised for use in userspace. Note, these are distinct from the linux-headers packages provided along size linux and do not need to be kept version synced with the running kernel. The usual practice is to only do a major version bump when updating another toolchain component, as major updates are rarely in demand.

Sources are signed by either Linus Torvalds (0xABAF11C65A2970B130ABE3C479BE3E4300411886) or Greg Kroah-Hartman (0x647F28654894E3BD457199BE38DBBDC86092693E), and sha256 sums are provided in a signed file in the source tarball directory

  • TODO: document reason for rsync as a makedepends
  • TODO: document using libdrm headers.

GNU C Library

Provided by glibc.

Second step of the toolchain, also, it needs to be rebuilt after a new gcc rebuild.

There are some packages that require a rebuild after a new glibc, regardless of a so bump, such as valgrind.

GNU Binutils

See DeveloperWiki:Toolchain maintenance/Binutils

GNU Compiler Collection

Provided by gcc.

Last (or first) step of the toolchain, and vital to building its entirety. Its update triggers a binutils and glibc rebuild, as well as other packages, like linux itself and libtool

The kernel has a strict check on gcc configure flags. So, if any flags are changed between package releases, even if it is the same gcc version, a kernel rebuild is required.

Other "Toolchain" Packages

These packages are closely tied to the toolchain, either as dependencies, or through the need for versioned rebuilds. Ideally these should be maintained by the toolchain team to ensure consistency.

  • mfpr
  • libmpc
  • dejagnu
  • elfutils
  • sysprof
  • ...