v0.12.9
Added
TPKG_FORMAT_RUNTIME(format_id 4): a runtime payload slot in the tpkg manifest — fat three-part packages (bootstrap + runtime payload + images) validate as well-formed; vendored into tebako and tebako-bootstrap from this header.linux-musl-arm64release leg (prebuilt libtfs + deps + mkdwarfs + tebakofs for musl/arm64) — enables the runtime-ruby musl-arm64 matrix and tebako prebuilt flows on arm64 Alpine.
Changed
- Release notes corrected for the current build/link reality (gnu legs in the ubuntu-20.04 ci container with static C++ runtime; musl legs static C++ runtime + shipped toolchain archives).
Release artifacts
Per-platform packages (platform ids: linux-gnu-x86_64, linux-gnu-arm64,
linux-musl-x86_64, linux-musl-arm64, macos-arm64, macos-x86_64,
windows-ucrt64):
libtfs-<version>-<platform>.tar.gz(.zipon Windows):lib/libtfs.a— the libtfs static librarylib/libtebako_dirent_helper_c.a— C helper archive (link dependency
of libtfs where the legacy tebako API is built; not shipped on Windows)include/tebako/**— public headerslib/cmake/libtfs/— CMake package config (find_package(libtfs))
libtfs-deps-<version>-<platform>.tar.gz(all platforms): the
transitive static libraries consumers link against —
libdwarfs_reader,libdwarfs_common,libdwarfs_metadata_legacy,
libdwarfs_decompressor,libflatbuffers,libzip,libfmt,
libxxhash,libzstd,liblz4,liblzma, brotli (dec/enc/common),
libz,libbz2,libboost_filesystem,libboost_chrono, plus
libcrypto/libsslon Linux and Windows (macOS consumers link
brew/system OpenSSL at link time) — with the CMake package configs
of those ports undershare/(orlib/cmake/where a port installs
there), sofind_dependencycan still resolve, and a curated
header set underinclude/(brotli/,zstd.h/zstd_errors.h/
zdict.h,lz4*.h,lzma.h+lzma/,zlib.h/zconf.h,
bzlib.h,fmt/,flatbuffers/,zip.h/zipconf.h,
xxhash.h/xxh3.h, plus theboost_filesystem/boost_chrono
subset ofboost/), so consumers can also compile against the
shipped archives (e.g. native gem extensions that include
<brotli/encode.h>).mkdwarfs-<platform>andtebakofs-<platform>— command-line tools
(.exesuffix onwindows-ucrt64)
Self-contained consumption: a libtfs-<version>-<platform>
package plus the matching libtfs-deps-<version>-<platform> package
are fully self-contained — compiling and linking against libtfs.a
needs no vcpkg (and no C++20 dependency build) on the consumer
machine, only a compiler, a linker and the platform system libraries
(plus brew/system OpenSSL on macOS).
Consumers that prefer to resolve dependencies themselves (e.g. their
own vcpkg) can keep using the libtfs package alone.
Linkage notes (from the shipped binaries' ldd/objdump output):
- All C/C++ third-party dependencies (dwarfs-t, libzip, fmt, Boost, …)
are statically linked into the binaries on every platform. linux-gnu-*: dynamic glibc only (built inside the tebako
ubuntu-20.04 ci container; libstdc++/libgcc linked statically —
runs on any glibc ≥ 2.31 system such as Ubuntu 20.04+).linux-musl-*: dynamic musl libc only (built on Alpine 3.21;
libstdc++/libgcc linked statically — runs on any musl system,
including tebako's older alpine-3.17 containers). The musl deps
packages additionally carry the build'slibstdc++.a/libgcc.a/
libgcc_eh.aso consumers on older toolchains can still close
the static link.macos-*: dynamic macOS system libraries only (libSystem, libc++;
built onmacos-14/macos-15-intel).windows-ucrt64: dynamic UCRT + MSYS2 runtime DLLs
(libgcc_s_seh-1.dll, pluslibwinpthread-1.dll/libstdc++-6.dll
for mkdwarfs); run inside MSYS2 UCRT64 or ship those DLLs alongside.
The Windows package ships the modern C/C++ API only (the legacy tebako
API needs the ruby build context).
SquashFS: shipped artifacts are built WITH_SQUASHFS=OFF — the
backends are dwarfs + zip only, so consumers are not forced to link
LGPL squashfs-tools-ng. POSIX source builds may opt into the SquashFS
backend (LGPL) with -DWITH_SQUASHFS=ON.
SHA-256 checksums for all artifacts: see the SHA256SUMS asset.