"SerenityOS on SerenityOS" checklist

[timschumi]

Preamble

This is an incomplete(!) list of things that I noticed to be missing when trying to build SerenityOS inside SerenityOS (much less successfully building or running).

Generally, building currently only works with Clang as the host compiler (so remember to export CC=clang CXX=clang++), as GCC is not position-independent and will quickly run into memory allocation issues.

The remaining ports that need to be installed can be found here. Remember to symlink bash to /bin/sh, as our Shell is not POSIX-compatible.

Build Instructions

1. Check out serenity-on-serenity-host from https://github.com/timschumi/serenity
2. Build the system and all required ports as listed here
3. Remember to bump SERENITY_RAM_SIZE, 1G is not enough
4. Symlink /bin/sh to bash in your sync-local.sh
5. Clone https://github.com/timschumi/serenity inside Serenity and check out the serenity-on-serenity branch
6. export CC=clang CXX=clang++
7. ./Meta/serenity.sh build i686 Clang for the whole system (includes the toolchain on first run) or ./Toolchain/BuildClang.sh for just the toolchain

TODOs (by descending importance, authors opinion)

Actual blockers

• [ ] Kernel of the nested Serenity instance locks up if it tries to enable UMIP
• [ ] Implement actual support for SO_REUSEADDR
• [ ] Figure out why QEMU rejects the default netdev

Issues with existing workarounds

• [ ] Support mounting ext2 images from files
• [ ] liblagom-core does not find syscall{1,2,3} (#15768)
• [ ] ~~Figure out why building LLVM using GCC generates a broken atomics.c.o (i.e. _c-suffix is not removed) (needs something like 8844762428a57558e4989b9d4df09ac35599551f, should be fixed upstream)~~
• [ ] Implement XZ support in tar (tar -xJf) and by extension LibCompress

Issues that are insignificant because GCC doesn't work anyways (#14189)

• [ ] Port texinfo/makeinfo (and by extension, perl) [binutils]
• [ ] _Unwind_Resume is "missing" [GCC]

DONEs (by order of materialization/completion)

• [x] Implement extended header support in tar (more precisely the path extensions for long file names) (#12876)
• [x] Implement selecting specific files for unzip (#12510)
• [x] Implement install -D (#12573)
• [x] Look into curl CA certificate validation without extra flags (#12959)
• [x] Implement RPATH/RUNPATH in the ELF loader (#12631)
• [x] #12956
• [x] Implement a cmp command [binutils] (#13137)
• [x] #12962 [binutils] (Has been worked around for this specific case)
• [x] Implement install -c (no-op?) [binutils] (#13018)
• [x] ~~Linker does not find many symbols~~ size_t mismatch between GCC and LLVM [LLVM] (#12991)
• [x] X86GenDisassemblerTables contains a malformed modRMTable [LLVM] (#13006)
• [ ] ~~Make python3 build the _ctypes module [LLVM runtimes]~~
• [x] Prevent ninja from invalidating all build output on x86_64 (#13581)
• [x] Clang overflows the stack while building itself on x86_64 (#13637)
• [x] Make pick_gcc less annoying when building with Clang (#13677)
• [x] #13816
• [x] ~~Implement ZIP data descriptors (test file)~~ (#14015)
• [x] compiler-rt runtimes experience random missed includes ("di_int: type name requires a specifier or qualifier") while compiling (appears if llvm/llvm-project@19c5cf4167f645ac4f612a32abcc4d5a469cb214 is present in the llvm Port) (#13949)
• [x] Make pls viable as a sudo-replacement (#14414)
• [x] ~~Support mapping files partially in unzip~~ (#14452)
• [x] Port QEMU (including tools) (#13971)
• [x] Implement cp --preserve=... (#14571)
• [x] Implement du -k (#14633)
• [x] CMake doesn't load the SerenityOS platform module when building on Serenity (#14647)

Most of these are currently worked around by additional patches (serenity-on-serenity-host for the modifications on the host, and serenity-on-serenity for the modifications for building), but obviously running patch-less is the target :^)

[circl-lastname]

Tar having XZ support would also need support for XZ in LibCompress

[IdanHo]

Tar having XZ support would also need support for XZ in LibCompress

That is all that is needed for for xz support in Tar, "tar.foo" just means a tar file that is compressed with foo.

[circl-lastname]

Uh, I know, but Serenity doesn't support it in LibCompress yet, that's why there's a port of xz available

[ben-abraham]

One down :^)

Selecting specific files for unzip

[ben-abraham]

As a pre-requisite, we will need an LZMA2 implementation before we can support XZ archives. They work with a 'filter' mechanism that apply multiple modifiers to files increase the odds of getting good compression ratios. The filters that XZ has documented include:

• LZMA2
• [6x] Branch/Call/Jump Filters for Executables
• Delta
• Custom I would imagine most archives use, at a minimum, the LZMA2 layer, but I'm sure others are used somewhat commonly. Doing a super simple test on linux, the archive was created with only a single LZMA2 layer, and used CRC64 for checksums (another thing to add 😄).

[timschumi]

As a pre-requisite, we will need an LZMA2 implementation before we can support XZ archives.

I believe @MaxWipfli is currently looking into this already. :^)

[MaxWipfli]

As a pre-requisite, we will need an LZMA2 implementation before we can support XZ archives.

I believe @MaxWipfli is currently looking into this already. :^)

Yes, I am working on it. I have only looked at decompression, which is already a pretty hefty task. I have almost fully implemented a basic usable version of the XZ container format and the beginnings of an LZMA2 decoder. I haven't really worked on the actual LZMA algorithm (which is a pain to implement due to a somewhat severe lack of documentation), but I already have basically everything else done. This means that files only consisting of uncompressed LZMA chunks (e.g. very short files with less than ~20 bytes) are basically decompressable now. Should have a draft PR (without actual LZMA) ready soon-ish (hopefully later today).

[archanox]

SInce the ca changes had landed, I thought I'd give building SerenityOS a go. As you can see in the attached screenshot there appears to be an issue with bintools not supporting the --prefix option, which I think has something to do with the shell? Another thing of note is that the decompression of the gcc and binutils takes a considerable amount of time. Downloading from git also appears to take more time than expected.

[timschumi]

As you can see in the attached screenshot there appears to be an issue with bintools not supporting the --prefix option, which I think has something to do with the shell?

Our Shell (which is symlinked to /bin/sh) is not POSIX-compatible, even though it should be. For now, you'll have to resort to building the bash port and symlinking /bin/sh to /usr/local/bin/bash in your sync-local.sh. That should also solve quite a few of the argument-related misconceptions that our own shell has.

Another thing of note is that the decompression of the gcc and binutils takes a considerable amount of time. Downloading from git also appears to take more time than expected.

I haven't looked at profiling the decompression yet, but yeah, it takes very long. If you want to look into that, I'd greatly appreciate it. For testing, I modified my local copy to skip deleting the folder if it is already present, which considerably cuts down on time when restarting the build.

[archanox]

Downloading from git also appears to take more time than expected.

I suspect something's iffy with the given message in the log [#0 NetworkTask(7:7)]: IPv4Socket(0xc34ab420): did_receive refusing packet since buffer is full. Which is spammed across the terminal when cloning from github

[timschumi]

Downloading from git also appears to take more time than expected.

I suspect something's iffy with the given message in the log [#0 NetworkTask(7:7)]: IPv4Socket(0xc34ab420): did_receive refusing packet since buffer is full. Which is spammed across the terminal when cloning from github

That should be handled by 0e970bba0a65db71c9d9ee193297f05a9a1e39de. While the message still appears occasionally, the cloning speed is much faster (and usually sufficient to handle the cloning speed that GitHub delivers on average).

[archanox]

The perl port is currently being tracked here https://github.com/SerenityOS/serenity/issues/1613

[archanox]

I've attempted another rebuild-toolchain with the latest changes to see where the current state of things are at.

With the default shell:

Similarly with bash:

[timschumi]

Not surprising, the scripts use /bin/sh everywhere. I have amended the issue to make mention of that.

[BertalanD]

Make pick_gcc less annoying when building with Clang

#13677