GeezerVison

This lets libgit2 build for WebAssembly with wasi-sdk, as a static library for wasm32-wasip1. There are ten small commits, each guarded by __wasi__ (or by CMake's WASI system name), so other platforms are unchanged.

WASI preview 1 offers a POSIX-like filesystem through wasi-libc. It has no sockets, processes, users, mmap or threads. With these changes the local parts of libgit2 work under any WASI runtime (repositories, objects, refs, index, checkout, diff, the local transport). Network access works through a custom transport or stream (git_transport_register / git_stream_register) that the embedder provides.

Commits

1. integer: type-generic overflow builtins on WebAssembly. On wasm32, size_t is unsigned long while SIZE_MAX == UINT_MAX. The SIZE_MAX tests therefore pick __builtin_uadd_overflow, and clang rejects every caller (-Wincompatible-pointer-types). __builtin_add_overflow/__builtin_mul_overflow are used there instead.
2. streams: no default socket stream on WASI. The BSD socket code is compiled out. The default stream returns an error asking for a registered stream or transport, and a custom GIT_STREAM_STANDARD registration is still used.
3. sysdir: no passwd database on WASI. No <pwd.h>/getpwuid_r/getuid. Home and XDG directories come from $HOME / $XDG_CONFIG_HOME only.
4. process: no unix process API on WASI. There is no fork/exec. Only the exec-based SSH transport uses it, and SSH is not available on WASI.
5. llhttp: no JavaScript callback imports on WASI. llhttp's api.c declares wasm_on_* imports for llhttp's own JS-hosted build, which leaves 8 undefined imports in any other wasm build that links it. (This one touches deps/llhttp. I'm happy to send it to llhttp as well, or to drop it if you'd rather carry it differently.)
6. rand: no process or user ids in the fallback seed on WASI. The seed comes from getentropy, which WASI has and CMake already detects. The time-based fallback leaves out getpid/getppid/getpgid/getsid/getuid/getgid, which WASI doesn't have.
7. fs_path: no file ownership on WASI. There are no users or geteuid, and stat reports no owner. WASI gets its own git_fs_path_owner_is that treats every existing file as the current user's, as on a single-user system, so the safe.directory checks pass.
8. cmake: build for WASI. NO_MMAP for CMAKE_SYSTEM_NAME WASI, so packs are read into memory as on other mmap-less platforms.
9. realpath: resolve paths below nested preopens on WASI. wasi-libc's realpath() calls readlink() on every prefix of the path. A prefix that is not inside a preopened directory fails, for example /a for the preopen /a/b. So with a preopen of more than one component, git_repository_init/open fail with "failed to resolve path". On WASI, such a path is resolved lexically and checked for existence instead. (The root cause is in wasi-libc; this keeps libgit2 usable with today's runtimes.)
10. posix: readlink with room to spare on WASI. Node's WASI (uvwasi) fails readlink() with ENOBUFS when the target fills the buffer exactly, where POSIX truncates. libgit2 passes buffers of the target's length, so under Node every symlink in a work tree fails diffs and status ("failed to read symlink data ... No buffer space available"). On WASI, the target is read into a buffer one byte longer.

Building

With wasi-sdk (tested with wasi-sdk 34, clang 23):

cmake -S . -B build-wasi -G Ninja \
  -DCMAKE_TOOLCHAIN_FILE=$WASI_SDK/share/cmake/wasi-sdk-p1.cmake \
  -DCMAKE_BUILD_TYPE=MinSizeRel -DBUILD_SHARED_LIBS=OFF -DBUILD_TESTS=OFF -DBUILD_CLI=OFF \
  -DUSE_THREADS=OFF -DUSE_HTTPS=OFF -DUSE_SSH=OFF -DUSE_AUTH_NTLM=OFF -DUSE_AUTH_NEGOTIATE=OFF
cmake --build build-wasi

This produces libgit2.a with no warnings. Bundled zlib, PCRE, llhttp, xdiff and SHA1DC are used.

Testing

I don't add CI here, and I'd welcome guidance if you want a WASI job (the clar suite would need a WASI runner such as wasmtime or Node, plus a list of tests that need sockets or processes).

What I checked:

• I linked the library, with a small wrapper, into a wasm32-wasip1 reactor module and ran it under Node's WASI, against git 2.43:
  • init, add and commit (git fsck --strict clean; the tree equals git write-tree);
  • opening repositories made by git (packed objects and refs, annotated tags);
  • revparse, tree entry by path, blob and raw tree content (byte-identical to git cat-file), ls-tree, refs;
  • diff of HEAD against the workdir with index;
  • git_checkout_tree from a bare repository into a target_directory (identical to git archive);
  • hard reset.
• I registered a custom smart subtransport for https (stateless RPC, I/O through a host-provided fetch) and used it to clone, shallow clone (depth = 1), unshallow fetch and ls-remote against github.com. The refs were identical to native libgit2 and git fsck was clean.
• with preopens of one and of several path components (/work, /a/b, a host path used as the guest path);
• on this branch (main) and on v1.9.7 (the same commits, branch wasi-v1.9.7).

Known WASI limits that need no code here: there are no permission bits, so core.filemode is detected as false at init and the executable bit is not restored on checkout. There is no chmod.

The patches, tests and this description were drafted with an AI agent (Claude Code, Claude Opus 5.5) and reviewed before opening.

🤖 Generated with Claude Code