Some notes:
- Zig removed support for z/OS[1] and with it some files from libc++
that we were using with patches originating from the LLVM port:
- libcxx/include/__support/ibm/locale_mgmt_zos.h
- libcxx/src/support/ibm/xlocale_zos.cpp
I put them back in and applied the previous patches, all in one big
change.
- The directory iterator code needs to be ported to the new std.Io
interface, but unlike before missing platforms are handled gracefully
by returning an error at runtime so I'll do this later.
- Minor parts of the patch set have been upstreamed[2][3], more will
follow.
[1]: https://github.com/ziglang/zig/pull/25731
[2]: https://codeberg.org/ziglang/zig/pulls/31916
[3]: https://codeberg.org/ziglang/zig/pulls/31931
i686 support war removed, so there is no need to pass -m64 explicitly.
Before i686 support was removed in b49c4eb94f, we used to pass -m32
for 32-bit systems here.
Additionally, installing multilib development packages like
libc6-dev-i386 should be unnecessary now, so the flashy warning message
can be removed.
This also makes the port compile on AArch64 now. Previously, it failed
to build because M_FLAG was undefined.
It still won't build on RISC-V since LuaJIT itself doesn't support
RISC-V yet (https://github.com/LuaJIT/LuaJIT/pull/1267).
This is better than hardcoding it to 0.
This new implementation is a direct copy of the IBM i implementation.
Neovim uses this count to determine how many threads to spawn in
`vim.pack`. Previously, it spawned 0 threads and got stuck when
downloading plugins.
LuaJIT switched to a rolling-release model with multiple maintained
branches.
This commit hash is the current head of the branch currently marked
as "production": v2.1.
This port uses incomplete function prototypes, which are no longer
supported as of C23.
Additionally, it failed to compile due to a missing <sys/select.h>
include. For some reason, there was already an upstream patch for this,
but it wasn't included in our patches.
The old version failed to build with
"error: cannot use keyword 'false' as enumeration constant."
The new version doesn't ship with a pre-built `./configure` script
anymore, so we need to run `autoreconf -i` manually.
Building with more than one job appears to broken.
Additionally, it relies on incomplete function prototypes, which C23
removed support for.
Furthermore, it doesn't build without
`-Wno-error=incompatible-pointer-types` anymore, as it passes
incorrect function pointer types to `qsort()`.
macOS ships tic 6.0.20150808 which fails to build terminfo for
ncurses 6.5. Bump the minimum required version to 6.1 so the
Homebrew tic is used instead.
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.
For some reason, this will become necessary in the next commit. This
library is already included in glibc so it is not needed to link against
it on Linux, but otherwise required.
These changes were upstreamed by timschumi a few years ago. The patch
was dropped by doing:
```
$ ./package.sh dev
$ git am --skip # As there are no changes on the git tree.
$ exit
```
