[RFC] Add support for SerenityOS

The SerenityOS Project is a hobbyist Unix-like/ELF desktop operating system with support for x86_64 and (WIP) aarch64 platforms. The project was started in 2018, and initially used a GCC patchset to bring up the cross-compilation environment. Since August 2021, we have maintained an llvm patchset to add a target triple, driver file, and support in libc++ for building the OS.

Compiler Support

The support for building the OS with either a GCC or Clang based toolchain are roughly equivalent at this point. We compile the entire OS stack in both Github Actions and Azure DevOps using both Clang and GCC and run a test suite in QEMU on every main branch commit and pull request.

In the summer of 2022, I upstreamed our CMake support, which made it into CMake 3.25.

I have been tracking the progress of upstreaming toolchain related patches to the various open source projects here on GitHub. Our patches are already upstream for config.sub, config.guess, and CMake.


Upstreaming the patches we have to LLVM, gcc, and binutils is the next step in upstreaming the rest of the patches in our Ports tree to be good FOSS citizens.

We undertake a ritual each LLVM and gcc release to rebase our patches on top of the latest release, which takes time away from developing parts of the operating system, test infrastructure and developer experience. Upstreaming the patches to LLVM would allow us to better dogfood upcoming LLVM changes, and reduce the impact that regressions have on our update process. The entire operating system is written in C++20, with custom libraries for everything from the Kernel to the C library to the Windowing system. Developers such as Daniel Bertalan have been very proactive in reporting trunk regressions in our core OS libraries to date. Having the patches upstream would make testing trunk changes much easier and more automate-able.

There is also some interest from external projects. The nixpkgs project [1] has expressed interest in supporting our Ports, but they are uncomfortable with the non-upstreaming of many of the patches we have. Contributors to the Zig language have expressed interest in supporting SerenityOS as a target, but the lack of upstream llvm support makes them carrying our patches a non-starter. A similar situation exists for Rust, where there are people interested in a Rust port to Serenity (which I made into a port [2] a few months ago). However, without support in upstream LLVM, adding support to rustlang/rust and rustlang/rust-libc is going to be a non-starter. And without at least a stage-1 rust port, no low level rust crates will be willing to add #[config(os_name == "serenity")] patches to allow porting more complex rust programs to the system.


SerenityOS has a robust contributor base, with ~900 contributors, ~1000 commits merged per month, and ~50 regular contributors each month. The set of core developers who work on toolchain changes is a bit smaller, and generally consists of myself, Daniel Bertalan, Tim Schumacher.


We would like to upstream the 12 patches or so that comprise our llvm patch set. This will hopefully decrease the friction of toolchain updates, help encourage more SerenityOS developers to engage with the LLVM community, and allow for downstream projects to have an easier time justifying incorporating patches to support SerenityOS.

I’m looking for feedback on the feasibility of upstreaming the patches I linked at the top of the post, and any infrastructure-related requirements that the project would be responsible for should the patches be accepted.

Extra links, since I’m only allowed 5

[1] nixpkgs: https://github.com/NixOS/nixpkgs/pull/186484#issuecomment-1608960696
[2] rust port: https://github.com/SerenityOS/serenity/pull/15935/files


Thank you for starting this discussion! I see no reason why we shouldn’t support these patches so long as SerenityOS maintainers are willing to help maintain the functionality within LLVM. Most of us don’t have access to a SerenityOS install, so fixing issues as they arise will be a challenge for us without your assistance. If you’re able to contribute a build bot for our test farm (How To Add Your Build Configuration To LLVM Buildbot Infrastructure — LLVM 17.0.0git documentation), that would help to quickly identify when we introduce issues with a change, but we may need more active assistance with resolving them.

@tstellar – does this have any impacts you’re worried about as release manager?
@MaskRay – do you have any significant driver concerns?
@ldionne – does this present problems for libc++ folks?

(I’m probably missing other folks who might have an opinion, so feel free to tag anyone you think should weigh in.)

1 Like

Is there a link to discourse/phabricator when the last OS was added?

Some recent examples I know of:

⚙ D131594 [Triple] Add triple for UEFI – adding UEFI
⚙ D138202 [OHOS] Add support for OpenHarmony – adding OpenHarmony OS (RFC at [RFC] Add support for OpenHarmony OS)


Thanks for the RFC! I looked at the libc++ patch and it doesn’t seem controversial to me (at all). It seems like it would be pretty easy to add support in libc++.

Our policy for adding support for new platforms requires adding a new CI job that tests that configuration. That way, we can make sure to avoid breaking you as we develop on main, which is mutually beneficial. Adding a new CI job is documented here: Adding New CI Jobs — libc++ documentation, and I can help you with getting a BuildKite token (just contact me on Discord).

We’ll be happy to take a look at the patch that adds support, adds the CI job and then we can list your platform as officially supported on our webpage (“libc++” C++ Standard Library — libc++ documentation).

Thanks for the feedback! I’ve created a diff stack starting with ⚙ D154395 [llvm] Add triple for SerenityOS. I re-ordered some of the commits, and squashed a few related to building llvm on SerenityOS itself (i.e. Stage 2 bootstrap, for the Port).

I’ll have to check with the other SerenityOS maintainers how we want to handle the BuildBot situation. It sounds like it would be reasonable to stand up a new cloud VM somewhere to handle both the zorg and the libcxx buildkite bot, to not bog down our current single GitHub Actions private runner.

1 Like

Thank you for the nice summary!
I have clicked “Accept” for the target triple patch and some compiler-rt patches. They look quite reasonable.
I made a comment on the Clang Driver patch that some testing is needed.
I have some concern about the -ftls-model= hack as I think proper support on SerenityOS side should be added instead.

1 Like