Support SerenityOS libc for cross compilation

[alexrp]

Serenity is straightforward to build: https://github.com/SerenityOS/serenity/blob/master/Documentation/BuildInstructions.md

It should be pretty easy to provide libc in exactly the same way we do for e.g. glibc and FreeBSD.

However, I have no idea if SerenityOS has a stable libc ABI at this point. cc @linusg

[linusg]

However, I have no idea if SerenityOS has a stable libc ABI at this point.

Definitely not, it doesn't really have any stability guarantees - that's kinda the point. Software is more fun when you don't have to think about backwards compat and can make breaking changes atomically across a single monorepo :^)

I'm no longer a maintainer but for the same cultural reasons I don't expect serenity to ever adopt a versioning scheme or releases. Anything older than master doesn't matter.

[alexrp]

I guess I can understand that perspective, though it's a bit unfortunate for a project like Zig that would like to support Serenity.

Perhaps as Serenity matures, there'll eventually be a subset of libc that's de facto "stable" (enough) for us to provide support for.

Alternatively, we could just provide stub symbols for all symbols that have ever appeared in Serenity's libc, with no effort to omit removed symbols, and leave it to users to deal with breakage.

[linusg]

Removals are rare, looking through the git history these are the only ones from recent years that stand out:

• SerenityOS/serenity@b16ec18
• SerenityOS/serenity@c1a4a0e
• SerenityOS/serenity@85a53ba

Additions are more common but usually fit into the category of "missing posix C symbols that every other libc had for decades, needed to build some port".

I don't think shipping a single unversioned serenity libc abilist that is a snapshot of master refreshed at a similar frequency as other libcs would be problematic.

[alexrp]

@linusg are there any libraries besides Userland/Libraries/LibC that we should consider to be part of "libc"? What about Userland/Libraries/LibSystem for example?

[linusg]

In the past there were separate LibM and LibPthread but they got merged into LibC so that should be all you need.

LibSystem is the only thing permitted to make syscalls, implemented by a bit of special casing in the dynamic loader: https://github.com/SerenityOS/serenity/blob/362b391726a9292e42f15e7015dae010df171e13/Userland/Libraries/LibELF/DynamicLinker.cpp#L396

LibC links to it, I'm not sure that's relevant to what you're trying to do.

[alexrp]

I asked about LibSystem in particular because I see syscall.h gets installed to /usr/include. But if that header is useless for anything but LibC, then I guess it doesn't matter.

[linusg]

Ah, I see, looks like there's two or three things in userland calling syscall() directly (e.g. https://github.com/SerenityOS/serenity/blob/362b391726a9292e42f15e7015dae010df171e13/Userland/Libraries/LibCore/SessionManagement.cpp#L20) but that's clearly an oversight - that's what the non-standard functions in https://github.com/SerenityOS/serenity/blob/master/Userland/Libraries/LibC/serenity.cpp are for.

[alexrp]

Another question: Does /usr/lib/Loader.so contain symbols that programs are supposed to link against, as with most other libcs? For example, the dynamic linker contains __tls_get_addr in glibc, and contains a bunch of dl* APIs on FreeBSD.