Sortix volatile manual
This manual documents Sortix volatile, a development build that has not been officially released. You can instead view this document in the latest official manual.
|PORTING(7)||Miscellaneous Information Manual||PORTING(7)|
guide for porting software/src/ports/example/example.port port(5) format. ./configure and Makefile scripts and the de-facto conventional behavior. Deficiencies are fixed via patches instead of being worked around. Ports with their own custom build system implementation should be improved if they don't implement the interface correctly. Generated files are preferably patched instead of their input files due to the difficulty regenerating them. For instance configure should be patched directly instead of configure.ac and likewise Makefile.in instead of Makefile.am. Ports must not bundle their dependencies as it's problematic to silently have multiple stale versions of the same library. If a port bundles a dependency unless it's installed, then the dependency must be made mandatory. Ports must both compile natively and cross-compile. Ports must assume the best about the host operating system when cross-compiling and unable to test for bugs. It must be possible to reasonably boostrap the latest ports collection from the latest stable release. /src/ports/example/example.port file with the meta information documented in port(5). Start the port by defining how to get the latest stable version of the upstream release:
NAME=example BUILD_LIBRARIES='libfoo libbar? libqux?' VERSION=1.2.3 DISTNAME=$NAME-$VERSION COMPRESSION=tar.gz ARCHIVE=$DISTNAME.$COMPRESSION SHA256SUM=b8d67e37894726413f0d180b2c5a8369b02d4a2961bb50d2a8ab6f553f430976 UPSTREAM_SITE=https://example.com/pub/example UPSTREAM_ARCHIVE=$ARCHIVE BUILD_SYSTEM=configure LICENSE=example DEVELOPMENT=true
cd /src make clean-sysroot make PACKAGES='example!'
rm -f repository/*/example.tix.tar.xz # delete stale binary package rm -f repository/*/example.version # optional make clean-repository # or: remove all binary packages
make clean-sysroot make PACKAGES='example!!'
du -h repository/*/example.tix.tar.xz tar -t -f repository/*/example.tix.tar.xz
make available-ports # Search for newly available versions of ports make upgrade-ports PACKAGES=example # Update example port make PACKAGES='example!!' # Find the new sha256sum # Verify the new sha256sum is authentic. make PACKAGES='example!!' # Any old patches may fail to apply. find ports/example -name '*.rej' -o -name '*.orig' make PACKAGES='example!!' # Regenerate patches on a successful build. sed -E '/^DEVELOPMENT=true$/d' ports/example/example.port make PACKAGES='example!!' # Final build and testing.
PACKAGESenvironment variable can be set to a subset of ports to upgrade. The build will fail and report the sha256sum observed upstream and the SHA256SUM variable must be manually updated once it has been verified as as authentic. The old patch will be reapplied and the build will fail if any hunks could not be applied. In that case, the .rej files contains the rejected hunks and the merge conflicts need to be resolved. Delete any .rej and .orig files afterwards and continue the build. The patch files with be regenerated on a successful build as usual. Finally perform the quality assurance and testing of new ports. config.sub file parses the build/host/target triplet and is duplicated into all software using autoconf. If the port ships a version older than 2015-08-20, configure will fail to parse the operating system:
checking host system type... Invalid configuration `x86_64-sortix': system `sortix' not recognized
| -aos* | -aros* | -cloudabi* | -sortix* \
V=1which can be made permanent using MAKE_VARS=V=1.
// PATCH: Use foo instead because bar doesn't work yet. #ifdef __sortix__ foo(); #else bar(); #endif
#if __has_include(<foo.h>) #include <foo.h> #endif
#!/bin/sh set -e [ -n "$TIX_INSTALL_DIR" ] mv "$TIX_INSTALL_DIR$PREFIX/share/foo" "$TIX_INSTALL_DIR$PREFIX/share/bar"
- Providing fallback implementations of missing standard library interfaces.
- Replacing buggy implementations of standard library interfaces.
- Sharing common utility functions between projects.
- The replacement implementations tend to be non-portable and one is supposed to modify the source code to rely on private standard library details that may be subject to change.
- Gnulib is highly forked by design and adding support for new operating systems needs to be done upstream and it may take years for the support to reach new downstream releases.
- Gnulib has assumed the worst in the past when cross-compiling, assuming unknown operating systems are buggy, injecting a non-portable replacement that doesn't compile, even when the standard library function is correct and could just have been used.
- Replacing standard library functions can hide bugs that would otherwise have found and fixed.
- Gnulib is not organized into the three categories and it's non-trivial to find out whether any interface has been replaced that shouldn't have been.
- There is no way to satisfy gnulib by correctly implementing the standard library without contributing explicit support upstream for new systems and committing to private implementation details.
--exec-prefixoptions correctly, failing to discern between an unset option and the empty value, which matters for the prefix where the default prefix (/usr/local) is different from the empty prefix (the root directory). Custom configure scripts sometimes fail to implement cross-compilation using the
--targetoptions to locate the compiler and cross-compiler.
CC_FOR_BUILDenvironment variable instead of
CCbefore falling back to a standard program. Likewise each toolchain variable has a counterpart for the build machine instead of the host machine, such as
PKG_CONFIGenvironment variable, and if unset, then using the
--hostoption to locate a cross-pkg-config, and finally falling back on invoking pkg-config(1) directly . Dependencies for the build machine should likewise be located using the
PKG_CONFIG_FOR_BUILDenvironment variable. Ports failing to use this search order may fail to cross-compile as they accidentally use dependencies from the build machine when cross-compiling to the host machine. The easiest fix is to use a shell parameter expansion:
PATH. These programs are inherently unable to support cross-compilation, as they provide answers about the build machine, and the host machine's bin directory cannot be executed on the current machine. Ports installing foo-config programs must be patched to not install them. pkg-config(1) configuration files should be installed instead. Ports invoking foo-config programs, even as a fallback, must be patched to unconditionally use pkg-config(1) instead.
PATHwhile the port is cross-compiled during the second phase.
DESTDIRenvironment variable as a secondary temporary prefix during the installation. The makefile may need to be patched to inherit the variable from the environment and to use it during the installation phase. The build will erroneously attempt to install onto the root directory of the build machine if the environment variable isn't respected. portability(7) lists common differences in the standard library. port(5) documents the advanced features useful for certain situations. Ports may fail at runtime instead of during compilation. Resolving these issues can require troubleshooting, debugging, research, and seeking help from the operating system developers and the upstream. Missing operating system functionality may need to be implemented. port(5), development(7), portability(7)
|March 19, 2022||Debian|