[RFC] Can embedded linux toolchain find runtime library in sysroot by default? (original) (raw)

February 17, 2025, 5:46pm 1

Hello!

I work at Arm and am currently working on creating a toolchain distribution that includes two different runtimes: picolibc and musl. These runtimes are bundled with the toolchain, and users can specify which one to use via the --sysroot CLI option.

This approach works well for the BareMetal toolchain (with --target=aarch64-none-elf) because its constructor adds sysroot/lib to the LibraryPaths. However, for the Linux toolchain (with --target=aarch64-unknown-linux-musl), it only looks for runtime libraries in the resource directory by default.

Before submitting a PR to modify the Linux toolchain constructor to also include sysroot/lib in LibraryPaths, I wanted to ask if there is a specific reason for the current behavior. Should this not be changed, or is it an oversight?

Thanks in advance for any insights!

smithp35 February 17, 2025, 7:18pm 2

I’m not entirely sure of the history behind this. I expect it is to do with emulating a GCC toolchain on Linux that may have some pre-configured behaviour. For example in the documentation: Directory Options (Using the GNU Compiler Collection (GCC))
says:

For example, if the compiler normally searches for headers in /usr/include and libraries in /usr/lib, it instead searches dir/usr/include and dir/usr/lib.

It is likely that /usr/include and /usr/lib is just an example for some GCC installations rather than a general rule for GCC though.

If you look through the code paths for computeSysRoot() in the Linux driver there is a lot of target specific directories added. One possible risk is that universally adding /lib to the linux driver could have some unforeseen consequences on some platforms with GCC emulation.

As an aside. For a musl based toolchain, using --target=aarch64-unknown-linux-musl, is there a need to put the runtime libraries in the sysroot?

The BareMetal toolchain has to do that because there are so many possible variants for the same target. However for a platform like Linux there should only be one runtime per target so it should be possible to use the resource directory.

The toolchain distribution can then use the resource directory in lib/clang/20.0/aarch64-unknown-linux-musl to locate the runtime when --target=aarch64-unknown-linux-musl, and when the bare-metal --target=aarch64-none-elf driver is used for Picolibc it can find the runtime in the sysroot/“multilib-path”/lib directories.

Granted this will make building the toolchain fun as we may need to build and install the aarch64-unknown-linux-musl runtime separately.