v0.12.7

Fixed

• Legacy fd read path clamps read/pread/readv to the open-time file size, so zero-length deduplicated files yield honest EOF instead of another file's bytes (defense-in-depth; root cause fixed in dwarfs-t tebako-v0.14.1-13, which ships in this release).
• dwarfs-t tebako-v0.14.1-14: std::atomic<bool> replaces std::atomic_flag, so dwarfs-t and its consumers build against ubuntu-20.04's stock libstdc++ (gcc-9/10, also under clang-18) with no libstdc++ >= 11 requirement.
• Linux tool binaries (mkdwarfs, tebakofs) link the C++ runtime statically (-static-libstdc++ -static-libgcc): the released musl/gnu binaries now start on hosts whose libstdc++ is older than the build container's.
• gnu release packages build inside the tebako ubuntu-20.04 ci container — shipped archives no longer reference glibc 2.38+ symbols (e.g. __isoc23_strtol via libcrypto), which broke consumers' ext/openssl configure checks on ubuntu-20.04.

Added

• tebakofs package tooling for tebako three-part packages (bootstrap + image slots + tpkg manifest trailer): bundle, unbundle, reassemble, insert-image, remove-image, set-runtime, mkimage (mkdwarfs wrapper; dwarfs only — the zip backend is read-only), and tebakofs info now detects and dumps a tpkg trailer while keeping archive-info behavior for plain image files.
• Release pipeline: per-platform libtfs-deps-<version>-<platform>.tar.gz package carrying the exact transitive static libraries consumers link against (dwarfs reader set, flatbuffers, libzip, fmt, xxhash, zstd/lz4/lzma/brotli/z/bzip2, boost filesystem+chrono; plus OpenSSL on Linux/Windows — macOS consumers link brew/system OpenSSL) together with those ports' CMake package configs. A libtfs package plus the matching libtfs-deps package are fully self-contained: no vcpkg needed downstream.
• libtfs-deps packages on Linux/musl now ship the matching include/openssl tree alongside libssl.a/libcrypto.a, so tebako's ruby build configures against a consistent OpenSSL 3.x.

Changed

• dwarfs overlay port: tebako-v0.14.1-16; man-page generation disabled (binaries-only artifacts).

---

Release artifacts

Per-platform packages (platform ids: linux-gnu-x86_64, linux-gnu-arm64,
linux-musl-x86_64, macos-arm64, macos-x86_64, windows-ucrt64):

• libtfs-<version>-<platform>.tar.gz (.zip on Windows):
  • lib/libtfs.a — the libtfs static library
  • lib/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 headers
  • lib/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/libssl on Linux and Windows (macOS consumers link
  brew/system OpenSSL at link time) — with the CMake package configs
  of those ports under share/ (or lib/cmake/ where a port installs
  there), so find_dependency can still resolve, and a curated
  header set under include/ (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 the boost_filesystem/boost_chrono
  subset of boost/), so consumers can also compile against the
  shipped archives (e.g. native gem extensions that include
  <brotli/encode.h>).
• mkdwarfs-<platform> and tebakofs-<platform> — command-line tools
  (.exe suffix on windows-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,
  jemalloc, Boost, …) are statically linked into the binaries on
  every platform.
• linux-gnu-*: dynamic glibc/libstdc++ (built on ubuntu-24.04;
  requires glibc ≥ 2.38 at runtime, e.g. Ubuntu 24.04 or newer).
• linux-musl-x86_64: dynamic musl libc + libstdc++/libgcc_s (built
  on Alpine 3.21; on a minimal Alpine install: apk add libstdc++ libgcc).
• macos-*: dynamic macOS system libraries only (libSystem, libc++;
  built on macos-14 / macos-15-intel).
• windows-ucrt64: dynamic UCRT + MSYS2 runtime DLLs
  (libgcc_s_seh-1.dll, plus libwinpthread-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.