v0.13.0

Added

• Six additive symbols in the modern C API, all dispatching to the owning mount of the fd/dir handle: tebako_fs_dir_is_embedded (dir-table membership test, the dir-handle counterpart of tebako_fd_is_embedded), tebako_fs_rewinddir/tebako_fs_telldir/tebako_fs_seekdir (index-based cookies — position is the ordinal of the next entry; backward seeks reset and advance), tebako_fs_pread (POSIX pread semantics via a new FileHandle::pread threaded through the dwarfs/zip/squashfs backends' offset-read primitives; the fd position is not modified), and tebako_fs_dlmap2file (modern entry point of the legacy tebako_dlmap2file mechanism with the same extraction/cache/lifetime semantics — extracts via the owning mount into a per-process temp dir, caches by memfs path; the returned string is caller-owned (free()), the extracted host file is owned by libtfs and removed at teardown).
• Multi-mount support in the modern C API: FsContext now keeps a mount table (tebako_mount_t handle → mount) instead of a single mount, with longest-mount-point-prefix path dispatch across mounts and per-mount fd/dir ownership. New additive symbols: tebako_fs_mount_from_file, tebako_fs_mount_from_file_at, tebako_fs_mount_from_memory (all returning a mount handle via out-param) and tebako_fs_unmount_handle (force-closes only that mount's fds/dirs). Compat shims are unchanged: tebako_fs_init* stays single-mount (EEXIST when any mount exists), tebako_fs_unmount() unmounts all, and tebako_get_mount_point/tebako_get_archive_path/tebako_get_backend_name keep reporting the init* mount. tebako_fs_extract_all extracts a single mount at the destination root as before; with multiple mounts each mount's tree goes into its own <dest>/<mount-point-basename> subtree.

Removed

• The legacy tebako C/C++ API (libdwarfs-wr lineage) is dropped in full, leaving the modern C API (<tebako/fs/c_api.h>: tebako_fs_*, tebako_get_*, tebako_is_initialized, tebako_path_is_embedded, tebako_fd_is_embedded, tebako_get_errno, tebako_strerror) as the only public surface. Removed: the file-ctl/file-io/dir-ctl/dir-io POSIX-shim quartet and its entire tebako_* libc-shim export surface (tebako_open/tebako_read/tebako_close/tebako_lseek/tebako_stat/tebako_opendir/…, 40 unmangled exports in total); tebako-io*/tebako-memfs*/tebako-fd/tebako-kfd/tebako-dirent and the mount/fd/kfd/memfs tables with their headers (both the top-level include/tebako-*.h layer and the legacy-only headers under include/tebako/fs/ — common.h, dirent.h, io.h, memfs.h, package_descriptor.h, internal/{fd_table,kfd,memfs_table,mount_table}.h); tebako-cmdline; tebako-package-descriptor; the legacy dl-ctl dlmap (tebako_dlopen/tebako_dlmap2file, superseded by tebako_fs_dlmap2file with the same extraction/cache/lifetime semantics); the memfs mount entry points (mount_root_memfs/mount_memfs_at_root/mount_memfs/unmount_root_memfs); the tebako-defines.h macro-redirection header; the RB_W32 ruby-win32 shim surface (tebako-io-rb-w32*.h, include/tebako/fs/ruby/) — i.e. the entire MinGW port surface; the pure-C tebako_dirent_helper_c helper library (its only consumer was the legacy tebako-dirent.cpp); and the WITH_LEGACY_TEBAKO_API CMake option with all of its guards. Legacy-only test suites and their fixture data (tests/tests-*.cpp, tests/test_filesystem*, tests/test_files, tests/empty, tests/resources, tests/package_descriptor) were removed as well; the modern suite is unchanged at 493 tests.

---

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 (.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, 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's libstdc++.a/libgcc.a/
  libgcc_eh.a so consumers on older toolchains can still close
  the static link.
• 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.

v0.12.10

---

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 (.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, 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's libstdc++.a/libgcc.a/
  libgcc_eh.a so consumers on older toolchains can still close
  the static link.
• 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.

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-arm64 release 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 (.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, 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's libstdc++.a/libgcc.a/
  libgcc_eh.a so consumers on older toolchains can still close
  the static link.
• 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.

v0.12.8

Fixed

• dwarfs-t tebako-v0.14.1-18 (same tree as -17): directory streams synthesize . and .. (POSIX readdir semantics) — packaged ruby's Dir.read contract (tebako patches-dir test) holds on libtfs images.
• dwarfs port: USE_JEMALLOC=OFF — consumers no longer inherit a shared jemalloc reference (brew dylib leak into tebako packaged binaries on macOS).

Changed

• dwarfs overlay port: tebako-v0.14.1-18 (identical content to -17; renamed after a vcpkg asset-cache poisoning by a propagation-lag download).
• musl deps packages now also ship the build's libstdc++.a/libgcc.a/libgcc_eh.a so tebako's musl link resolves the dep set's references (e.g. _M_replace_cold from libstdc++ >= 13) on older-toolchain containers (tebako alpine-3.17, gcc-12); musl release legs stay on alpine:3.21 with musl-native cmake (the xpack cmake is a glibc binary and cannot run on musl).

---

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.

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.

v0.12.6

Added

• libtfs-deps packages now include curated headers (brotli, zstd, lz4, lzma, fmt, flatbuffers, boost fs+chrono, …) so packaged native gem extensions build without vcpkg.

---

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.

v0.12.5

Added

• Self-contained libtfs-deps-<ver>-<platform> release packages (transitive static libs) — consumers need no vcpkg on the prebuilt path.

---

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.
• 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 — linking libtfs.a needs no vcpkg (and no
C++20 dependency build) on the consumer machine, only 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.

v0.12.4

Fixed

• dwarfs-t tebako-v0.14.1-12: fix nondeterministic mount/read failures (file_extents_iterable UAF — the iterable now owns a copy of the extents).

---

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))
• mkdwarfs-<platform> and tebakofs-<platform> — command-line tools
  (.exe suffix on windows-ucrt64)

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.

v0.12.3

Fixed

• Exit-time static destruction order: singleton tables (memfs/mount/fd/kfd/dir) are now constructed at mount time so packaged binaries no longer abort with "Unhandled exception" (SIGABRT) on process exit.

---

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))
• mkdwarfs-<platform> and tebakofs-<platform> — command-line tools
  (.exe suffix on windows-ucrt64)

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.

v0.12.2

Fixed

• dwarfs-t backend bumped to tebako-v0.14.1-11: fixes corrupt reads for
  duplicate-content files (flatbuffers reader resolved deduplicated chunks to
  the wrong inode). No libtfs API changes.

---

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))
• mkdwarfs-<platform> and tebakofs-<platform> — command-line tools
  (.exe suffix on windows-ucrt64)

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.