Repository containing the build scripts and infrastructure for Wonderful's Pacman-based packaging.
| Target | Description | Container |
|---|---|---|
| linux/x86_64 | Linux, x86_64 | linux/x86_64 |
| linux/aarch64 | Linux, AArch64 | linux/aarch64 |
| windows/x86_64 | Windows, x86_64 | windows/x86_64 |
| Target | Description | Container |
|---|---|---|
| linux/armv6h | Linux, ARMv6+, hard float | linux/arm32v6 |
| linux/riscv64 | Linux, RISC-V | linux/riscv64 |
The build system is not well tested outside of my own computers, so the steps may not be fully complete. Caveat emptor.
Arch Linux on an x86_64 or AArch64 machine is recommended.
- On Arch Linux,
python-uv,podman,qemu-user-staticandqemu-user-static-binfmtshould be installed, probably among some others. - On Debian,
pipx+pipx install uv,qemu-user-binfmt,qemu-user-static.
Some additional configuration steps have to be undertaken:
- Make sure to install
qemu-user-static-binfmtand notqemu-user-binfmt; otherwise, podman will error withexec container process (missing dynamic library?) '/bin/sh': No such file or directory. - For building on non-native architectures, the QEMU static interpreter has to run with root permissions. Not doing so will lead to an
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?error. On Arch Linux, this can be resolved using the following steps:- Edit the following files to replace the trailing flag
FwithFOC, orFPwithFPOC:
/usr/lib/binfmt.d/qemu-arm-static.conf/usr/lib/binfmt.d/qemu-aarch64-static.conf- etc.
- Run
systemctl restart systemd-binfmtto apply changes.
- Edit the following files to replace the trailing flag
- For building on MSYS2 via WINE and Docker on recent CPUs, the Linux kernel has to be launched with PKU/PKRU disabled due to a Cygwin bug by passing
nopkuon its command line. See msys2-runtime/#295 for more information.
Manual installation instructions:
- Install the latest version of MSYS2.
- The repository must be installed to
/wf. Whilepkgtoolis directory-agnostic, thePKGBUILDscripts are not. - Use the UCRT64 environment to work with
pkgtool. - Install UCRT64 Python and SSL certificates (required for
mirror):pacman -S mingw-w64-ucrt-x86_64-ca-certificates mingw-w64-ucrt-x86_64-python mingw-w64-ucrt-x86_64-python-uv. - Install build dependencies (this list is probably not 100% complete):
pacman -S autoconf autoconf-archive automake base-devel bison flex git libtool lld mingw-w64-ucrt-x86_64-autotools mingw-w64-ucrt-x86_64-cmake mingw-w64-ucrt-x86_64-lua-luarocks mingw-w64-ucrt-x86_64-meson mingw-w64-ucrt-x86_64-toolchain nasm ninja. - Copy
misc/windows/makepkg.confto/etc/makepkg.conf. - To fix
luarocksnot being able to create directories, you will need toluarocks install luafilesystemfirst, while creating all the erroring directories manually. See MINGW-packages/#12002.
Notes:
wf-pacmanis built with MSYS rather than UCRT64. This currently appears to require a separate, manual installation of uv via pip.- For an unknown reason,
wf-soxexpects/msys64/usr/share/aclocalto have the contents of/usr/share/aclocal.
Before using pkgtool for the first time, one should initialize the uv-based virtual environment:
$ uv sync
To start working with pkgtool, one must make mirrors of all the relevant repositories. This can be done by writing:
$ ./pkgtool mirror -c [targets...]
If no targets are specified, all targets supported by your environment will be downloaded. The -c argument removes all outdated/unused packages.
Example call:
$ ./pkgtool build wf-tools@x86_64,aarch64 target-wswan-examples
The @x86_64 suffix can be used to narrow down a build to specific architectures. This is useful for quicker building and testing of in-development packages.
After upgrading MSYS2, runtime-gcc-libs usually has to be updated. Failure to do so will lead to failures on trying to run EXEs in user installations.
The Linux bootstraps are effectively self-contained repackagings of a pre-installed wf-pacman package, allowing easy end user installation.
$ ./pkgtool build-bootstrap [targets...]
As the Wonderful toolchain is open source, it can be forked to provide custom builds. While the licensing terms are formally binding, I would like to additionally request holding to the following guidelines when developing a fork:
- Do not call your fork "Wonderful". It's okay to refer to it informatively as a fork of the Wonderful toolchain, but it's not okay to imply that your fork is the Wonderful toolchain. To change the toolchain's brand name in built executables, edit
WF_NAMEinconfig/runtime-env-vars.sh. - Make sure to document it clearly that any issues with the fork should be reported to you and/or the maintainers of the fork. To change the bug report URL used by GCC and some other programs, change
WF_BUGURLinconfig/runtime-env-vars.sh. - If your fork breaks compatibility with the Wonderful toolchain in any way (including porting to a platform or architecture not supported by the toolchain), please use a different
WONDERFUL_TOOLCHAINlocation than/opt/wonderful. This allows upstream to create its own version in the future without causing conflict between the two. This is achievable for the most part by changingWF_LOCAL_PATHinconfig/runtime-env-vars.sh, but it may require additional changes as well.
Unless otherwise specified, the build scripts (config/, packages/) are licensed under Creative Commons 0. I don't see why instructions on building otherwise libre toolchains should be restricted by copyright in any way.
The Python package management tool (tool/) is licensed under the MIT license.
If you'd like to use these scripts and/or tools to build your own repository or toolchain, I'd appreciate it if steps were made to ensure that such toolchains are not misrepresented as my own work.
