Bootstrap scripts

The reference implementation is a single-file executable. A dk0 wrapper script - a shell script on Unix and a dk0.cmd batch script on Windows - bootstraps and runs it. It relies on a small set of external tools per platform; a different implementation may use different tools or none at all.

Each dk0 version installs into its own dk0exe-<version>-<abi> directory under the dk0 wrapper script data home (%LOCALAPPDATA%\Programs\dk0 on Windows, $XDG_DATA_HOME/dk0 or ~/.local/share/dk0 on Unix, DKCODER_DATA_HOME override). The dk0 wrapper scripts garbage collect that store on every run: the version being launched is marked used, then version directories and superseded verifier/mlfront-signify-* binaries that no dk0 wrapper script has used in 30 days are removed. Everything in the store re-downloads on demand from its signed manifest, so pruning is always safe and never blocks a launch.

Engine version selection

The dk0 wrapper script resolves the engine version it downloads from three sources, in order of precedence:

• A %% actual_version("X.Y.Z.W") line in the dk.u ## workspace section fixes the version at X.Y.Z.W. Without that line the wrapper script resolves the latest version the base URL serves.
• DK0_BASE_URL is the base URL the wrapper script reads the signed manifest and the dk0 binary from, and defaults to https://diskuv.com/dk. A value naming a .../packages/generic/dk-dist/<version> folder resolves the one version that folder holds, which is the version a CI job pinned to that folder runs.
• --self-update as the first argument makes the wrapper script resolve the latest version and rewrite the dk.u actual_version line to it.

The dk0 wrapper script verifies each manifest against a baked signify public key, and downloads the dk0 binary only from the github.com/dkpkg/CommonsBase_Dk repository or the dk-dist GitLab package registry at gitlab.com/api/v4/projects/60486861.

When a %% actual_version("X.Y.Z.W") pin is present, the wrapper script refuses a verified manifest whose version is older than X.Y.Z.W. Without a pin the wrapper script accepts the latest version the base URL serves.

Windows POSIX shells

On Windows the dk0 wrapper script runs under Git Bash, MSYS2, and Cygwin, and dk0.cmd runs under cmd.exe and PowerShell. Both select the windows_x86_64 or windows_x86 binaries and share one dk0 wrapper script data home, %LOCALAPPDATA%\Programs\dk0, so a project driven from both shells downloads each version once.

The wrapper script looks for curl and wget in /usr/bin and /bin first, and then on PATH. The PATH step is what finds /mingw64/bin/curl under Git for Windows.

Windows

File	What
pwsh in PATH	enter-object interactive shell (optional; searched 1st)
powershell in PATH	enter-object interactive shell (optional; searched 2nd)
cmd in PATH	enter-object interactive shell (fallback; searched last)
powershell.exe in PATH	dk0 wrapper script - for InvokeWebRequest (optional; searched 1st)
bitsadmin in PATH	dk0 wrapper script - for download (fallback; searched last)
certutil in PATH	dk0 wrapper script - verify sha256sums
forfiles in PATH	dk0 wrapper script - prune old dk0 versions (optional)

macOS

File	What
/usr/bin/codesign	executables are locally signed when -e GLOB_PATTERN
/bin/sh	enter-object interactive shell unless SHELL env var set
/bin/sh	dk0 wrapper script
/usr/bin/shasum	dk0 wrapper script
/usr/bin/curl	dk0 wrapper script (optional; searched 1st)
/bin/curl	dk0 wrapper script (optional; searched 2nd)
/usr/bin/wget	dk0 wrapper script (optional; searched 3rd)
/bin/wget	dk0 wrapper script (optional; searched 4th)
curl/wget in PATH	dk0 wrapper script (fallback; searched last)
/usr/bin/mv	dk0 wrapper script (optional; searched 1st)
/bin/mv	dk0 wrapper script (fallback; searched last)
/usr/bin/rm	dk0 wrapper script (optional; searched 1st)
/bin/rm	dk0 wrapper script (fallback; searched last)
/usr/bin/uname	dk0 wrapper script (optional; searched 1st)
/bin/uname	dk0 wrapper script (fallback; searched last)
/usr/bin/awk	dk0 wrapper script - to parse sha256sums (optional; searched 1st)
/bin/awk	dk0 wrapper script (fallback; searched last)

Linux / BSDs / MSYS2 / Cygwin / Git Bash

File	What
/bin/sh	enter-object interactive shell unless SHELL env var set
/bin/sh	dk0 wrapper script
/usr/bin/shasum	dk0 wrapper script (optional; searched 1st)
/usr/bin/sha256sum	dk0 wrapper script (fallback; searched last)
/usr/bin/curl	dk0 wrapper script (optional; searched 1st)
/bin/curl	dk0 wrapper script (optional; searched 2nd)
/usr/bin/wget	dk0 wrapper script (optional; searched 3rd)
/bin/wget	dk0 wrapper script (optional; searched 4th)
curl/wget in PATH	dk0 wrapper script (fallback; searched last)
/usr/bin/mv	dk0 wrapper script (optional; searched 1st)
/bin/mv	dk0 wrapper script (fallback; searched last)
/usr/bin/rm	dk0 wrapper script (optional; searched 1st)
/bin/rm	dk0 wrapper script (fallback; searched last)
/usr/bin/uname	dk0 wrapper script (optional; searched 1st)
/bin/uname	dk0 wrapper script (fallback; searched last)
/usr/bin/awk	dk0 wrapper script - to parse sha256sums (optional; searched 1st)
/bin/awk	dk0 wrapper script (fallback; searched last)
/usr/bin/cygpath	dk0 wrapper script (optional)

Dynamic linker (per ABI, not per OS)

The tables above list files that vary by operating system. The dynamic linker is the exception: it varies by ABI. A dynamically linked executable names its loader by absolute path in its ELF PT_INTERP header, so that exact path must exist to run objects of that ABI. Statically linked objects carry no PT_INTERP and need no loader. The loader is normally supplied by the host's own libc, and must be provided explicitly only when objects of one ABI run on a host of another.

ABI	File	What
Linux_arm64	/lib/ld-linux-aarch64.so.1	glibc dynamic linker for dynamically linked objects
Linux_x86	/lib/ld-linux.so.2	glibc dynamic linker for dynamically linked objects
Linux_x86_64	/lib64/ld-linux-x86-64.so.2	glibc dynamic linker for dynamically linked objects

Minimum glibc (per ABI)

The published Linux binaries are built on manylinux_2_28 container images, so they run on any distribution carrying glibc 2.28 or newer.

ABI	Minimum libc
Linux_arm64	glibc 2.28
Linux_x86	glibc 2.28
Linux_x86_64	glibc 2.28

• No check reads the glibc versions a published binary requires or runs the binary on a glibc 2.28 distribution.

System toolchains (per-ABI contract)

Slot artifacts that contain native code are built with one system toolchain per ABI family. This section is the contract for where that toolchain comes from and what compatibility floor the built artifacts inherit. The repositories whose builds enforce these requirements document their own checks.

ABI family	System toolchain	How it is located
Linux_* (glibc)	gcc, as, binutils	resolved from PATH at build time
Windows_*	MSVC	at consume time: vswhere, then vcvarsall capture
Darwin_*	/usr/bin/clang	fixed path (selected developer directory: Command Line Tools or full Xcode)

• Linux_* (glibc): distribution builds must run in a build environment whose glibc is 2.28 or older, canonically the quay.io/pypa/manylinux_2_28_* containers, so slot artifacts run on any distribution carrying glibc 2.28 or newer.
• Linux_* (glibc): glibc links are backward-compatible only, so a build on a newer-glibc host inherits that host's glibc floor.
• Linux_* (glibc): runtime objects are compiled as position-independent code, so native links succeed under PIE-default toolchains.
• Windows_*: MSVC is the sole official Windows slot toolchain, and CommonsBase_LLVM.Toolchain.MinGW is a cross toolchain for building C userland packages. No check enforces either statement.
• Windows_*: vswhere finds the Visual Studio installation, a version in the range [16.0,19.0) carrying the Microsoft.VisualStudio.Component.VC.Tools.x86.x64 component.
• Windows_*: a vcvarsall environment capture supplies INCLUDE, LIB, LIBPATH and PATH, and the slot determines the vcvarsall architecture. No check confirms the captured variables.
• Darwin_*: /usr/bin/clang is the xcrun trampoline, which runs the clang of the developer directory xcode-select has selected. The build environment has a developer directory selected, either the Xcode Command Line Tools or a full Xcode installation, so xcode-select -p succeeds and /usr/bin/clang runs.