cc0939a666
While `pc` is not particularly wrong on x86_64, it's nonsensical on other supported platforms, namely aarch64 and riscv64. For consistency, we now don't use this vendor anymore, regardless of the platform. Within the LLVM project, we now build as `$arch-serenity`. This is enough in most cases, the only place where we have to specify a vendor is the target .cfg file where we use `$arch-unknown-serenity`. When building GCC and friends, again we simply identify as `$arch-serenity` and this is enough. As a result, the tools in Toolchain/Local/$arch/bin are now named after this pattern: `$arch-serenity-$tool`. These changes affect the toolchain build scripts, serenity's build scripts and the Ports. The last place where we should see `x86_64-pc-serenity` is the output of `config.sub`, which assume the vendor is `pc` on vendor-less `x86*` triples. So `x86_64-serenity` is expanded to `x86_64-pc-serenity`, luckily enough and AFAICT, the whole GNU ecosystem considers `pc`, `unknown` and vendor-less target triples the same. So `configure` shouldn't have an issue finding the right tools anyway. The gn files were edited with sed and are not tested. This commit also includes a check in `Meta/serenity.sh` to give a nicer error message when trying to build the system with an old toolchain. ---- To test this patch, on a clean tree I: - Ran `./Meta/serenity.sh x86_64 GNU` - Ran `./Toolchain/BuildJakt.sh` - Tested these ports: python3(configure based), libjxl(cmake based) and rizin(meson based) - Also booted on aarch64 and risv64 I also repeated the steps above with a Clang toolchain. On a working tree I tested all the affected ports, the results are: - tinycc build fine but can't compile programs, I observed the same on master. - gdb and epsilon don't build but report the same errors as on master. - I manually edited the libgpg-error, and it builds fine. - The gcc port works fine.
Library stubs
This directory contains stubs for SerenityOS's LibC that are referenced from the LLVM runtime
libraries. These are needed by the linker in order to add the required DT_NEEDED entries and to
not emit errors regarding undefined libc symbols. Additionally, it provides fake empty libunwind.so
and libc++.so for CMake configuration checks to succeed when bootstrapping the OS.
Do these need to be updated?
Most likely no but it depends. Either way, if you are reading this, you are probably qualified enough to figure out if a failing LLVM toolchain configuration or build is caused by an out-of-date LibC stub.
How to generate LibC stub?
First, you need to compile the LLVM toolchain and the SerenityOS's LibC. This will be a bit awkward
(see discussion at https://github.com/SerenityOS/serenity/pull/23960) until (unless) we solve the
dependency cycle between LibC and libunwind. Then, using the llvm-ifs tool,
Userland/Libraries/LibC/libc.so can be converted into a stripped-down stub form. To do that, run
the following command:
Toolchain/Local/clang/bin/llvm-ifs --output-elf=<path-to-stub> <path-to-original>
How to generate empty.so?
Simple, my friend:
touch empty.cpp
Toolchain/Local/clang/bin/clang++ --target={arch}-serenity -nostdlib -shared empty.cpp -o empty.so
# And optionally,
Toolchain/Local/clang/bin/llvm-strip empty.so