vcswatch reports that
this package seems to have new commits in its VCS but has
not yet updated debian/changelog. You should consider updating
the Debian changelog and uploading this new version into the archive.
Here are the relevant commit logs:
commit f5e2c52a5b8adec845f35746117794fb20e27859
Author: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Date: Wed Oct 15 14:54:18 2025 +0200
update d/copyright
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
commit e0befbc58f626f0fee79a784067ab8d32bb90578
Author: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Date: Wed Oct 15 14:49:40 2025 +0200
bump version to 0.0~git20250726.3f7eb4c-1
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
commit 167622a5a724cc5ddd8a241bd939ff21c5a064d7
Author: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Date: Wed Oct 15 14:18:26 2025 +0200
build: fix compiler-rt linkage
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
commit ff0cb677e884ed25c26a386bb526437ca0795ba7
Author: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Date: Wed Oct 15 14:02:09 2025 +0200
cherry-pick wasi-p2 build fix from upstream
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
commit 22106bb4af86e7453dd92865c811372fdf52910f
Author: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Date: Wed Oct 15 13:45:17 2025 +0200
rebase patches
Gbp-Dch: ignore
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
commit 1af12131b30c034aab32cdcb94757bd257ef968b
Author: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Date: Wed Oct 15 13:45:07 2025 +0200
prepare changelog
Gbp-Dch: ignore
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
commit 5573b908f5a2741d1273177c8bf50ee9a0eebe54
Merge: 9a0278c 1f765f4
Author: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Date: Wed Oct 15 13:42:43 2025 +0200
Update upstream source from tag 'upstream/0.0_git20250726.3f7eb4c'
Update to upstream version '0.0~git20250726.3f7eb4c'
with Debian dir e25126d8ac263af151ada75431d2b0e51758bd93
commit 1f765f427dfdd3006efab9d24dacb098d0c7c015
Merge: 4b5e8ae 3f7eb4c
Author: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Date: Wed Oct 15 13:42:42 2025 +0200
New upstream version 0.0~git20250726.3f7eb4c
commit 3f7eb4c7d6ede4dde3c4bffa6ed14e8d656fe93f
Author: Catherine <whitequark@whitequark.org>
Date: Sun Jul 27 00:30:31 2025 +0100
Refactor stub pthread library and enable unconditionally (#602)
This PR changes the layout of the stub pthread library to match that of
libc-top-half: splits it into (mostly) one file per function, and
ensures the same API is exposed from both libraries, adding stub
functions as necessary.
This PR also removes `-lwasi-emulated-pthread` as well as
`-D_WASI_EMULATED_PTHREAD` and enables this functionality
unconditionally, seeing as this is necessary for building libc++ with
threading enabled.
It adds a flag `-D_WASI_STRICT_PTHREAD` that causes thread creation
functions (`pthread_create`, `pthread_detach`, `pthread_join`) to be
defined as a macro causing a compile error, which can be used to locate
the parts of a codebase requiring changes for the single thread model.
Specifically, after this commit, the two targets `wasm32-wasip1` and
`wasm32-wasip1-threads` differ as follows (cleaned up for clarity):
```diff
--- expected/wasm32-wasip1/defined-symbols.txt
+++ expected/wasm32-wasip1-threads/defined-symbols.txt
+flockfile
+ftrylockfile
+funlockfile
+sem_destroy
+sem_getvalue
+sem_init
+sem_post
+sem_timedwait
+sem_trywait
+sem_wait
+wasi_thread_start
```
```diff
--- expected/wasm32-wasip1/predefined-macros.txt
+++ expected/wasm32-wasip1-threads/predefined-macros.txt
+#define _REENTRANT 1
+#define SEM_NSEMS_MAX 256
+#define SEM_VALUE_MAX 0x7fffffff
+#define __wasm_atomics__ 1
+#define __wasm_bulk_memory__ 1
```
commit db46bf790e0ecdfb887a4f91f953a9ea75762e8f
Author: Tim Chevalier <tjc@igalia.com>
Date: Fri Jul 25 13:58:38 2025 -0700
Fix typo in comment (#601)
As suggested by @alexcrichton in a comment on
https://github.com/WebAssembly/wasi-libc/pull/599 , I'm submitting a
small PR so that my future PRs will auto-trigger CI.
commit 45252554b765e3db11d0ef5b41d6dd290ed33382
Author: Nuno Cruces <ncruces@users.noreply.github.com>
Date: Fri Jul 18 00:15:05 2025 +0100
Optional SIMD strchrnul (#594)
Continuing #580. `strchrnul` is used by `strchr`, `strcspn` and many
other places in libc. The implementation is a matchup between `strlen`
and `memchr`.
commit 4ea6fdfa288e15a57c02fe31dda78e5ddc87c3c7
Author: Nuno Cruces <ncruces@users.noreply.github.com>
Date: Fri Jul 11 18:07:11 2025 +0100
Optional SIMD memchr (#592)
Continuing #580, followup to #586.
Chose `memchr` because it's somewhat similar to `strlen`, but also
because it is the basis for `strnlen` (and in that capacity, for
`strndup` and `strlcat`) and is also used by `strstr`, `fnmatch`.
commit 50ae11904df674fecaa311537967fe138c21fcc7
Author: Alex Crichton <alex@alexcrichton.com>
Date: Thu Jul 3 04:54:30 2025 +0200
Refactor how compiler-rt is managed in CI and locally (#591)
Building the PIC version of libc.a is currently broken with LLVM 19+,
and it's due to how this repository handles the compiler-rt library.
This PR refactors the handling to automatically download an appropriate
copy and handle it internally or otherwise use a `BUILTINS_LIB` from the
environment. This means that it's now always available for `libc.so`
which is needed to fix the build issue with LLVM 19+
commit 88e442769f1deec7e87af4cc6615a9b183631671
Author: Alex Crichton <alex@alexcrichton.com>
Date: Thu Jul 3 04:49:27 2025 +0200
Use inline assembly in strlen for vector loads (#593)
This commit is a refinement of #586 to use inline assembly to perform
vector loads instead of using a C-defined load. This is done to avoid UB
in LLVM where C cannot read either before or after an allocation. When
`strlen` is not inlined, as it currently isn't, then there's not really
any reasonable path that a compiler could prove that a load was
out-of-bounds so this is issue is unlikely in practice, but it
nevertheless is still UB. In the future the eventual goal is to move
these SIMD routines into header files to avoid needing multiple builds
of libc itself, and in such a situation inlining is indeed possible and
a compiler would be capable of much more easily seeing the UB which
could cause problems.
Inline assembly unfortunately doesn't work with vector output parameters
on Clang 19 and Clang 20 due to an ICE. This was fixed in
https://github.com/llvm/llvm-project/pull/146574 for Clang 21, but it
means that the SIMD routines are now excluded with Clang 19 and Clang 20
to avoid compilation errors there.
commit 553305fcc23b879ecd736e5deec874d3f108214c
Author: Nuno Cruces <ncruces@users.noreply.github.com>
Date: Tue Jul 1 00:18:06 2025 +0100
Optional SIMD strlen (#586)
This is a potential first step at upstreaming #580 piecemeal.
Chose `strlen` as it's already covered by tests. It's also one of the
simplest (easiest to review) implementations.
Built and tested with:
```sh
CC=[PATH_TO]/wasi-sdk-25.0-x86_64-linux/bin/clang \
EXTRA_CFLAGS="-O2 -DNDEBUG -msimd128 -mbulk-memory -D__wasilibc_simd_string" make
(cd test ; CC=[PATH_TO]/wasi-sdk-25.0-x86_64-linux/bin/clang make )
```
commit 205dd234880179180c9fe29bddb98a00eb2edd52
Author: Yuta Saito <kateinoigakukun@gmail.com>
Date: Thu Jun 26 03:09:20 2025 +0900
Revert "Skip pthread_cond_busywait test in browser tests (#589)" (#590)
Update @bjorn3/browser_wasi_shim to version 0.4.2. This release includes
a limited polyfill for `poll_oneoff`, which is necessary for the
`pthread_cond` test to pass in the browser.
https://github.com/bjorn3/browser_wasi_shim/pull/88
commit 1377a93acea031acd9b6e77a830360d88477319c
Author: Yuta Saito <kateinoigakukun@gmail.com>
Date: Fri Jun 20 09:48:26 2025 +0900
Skip `pthread_cond_busywait` test in browser tests (#589)
The `pthread_cond` test uses `nanosleep` which eventually calls
`poll_oneoff` but `@bjorn3/browser_wasi_shim` does not implement it. So
we skip the test for now, but we will revisit it later once
https://github.com/bjorn3/browser_wasi_shim/pull/88 is merged.
commit 859062ba28ffc5633bfa1ff300611a53f6ecf7d6
Author: Yuta Saito <kateinoigakukun@gmail.com>
Date: Fri Jun 20 07:58:00 2025 +0900
Opt-in busywait mode for futexes (#562)
We are heavily using wasi-libc + wasip1-threads on browsers. Since
wasi-libc uses `memory.atomic.wait32` to implement futex, and the usage
of `memory.atomic.wait32` on the main thread is prohibited on browsers,
we currently need to write code carefully not to reach the instruction.
Emscripten addresses this limitation by [employing a busy-wait on the
main
thread](https://github.com/emscripten-core/emscripten/blob/058a9fff/system/lib/pthread/emscripten_futex_wait.c#L111-L150)
as a workaround. Rust has [always employs busywait regardless of the
current thread is
main](https://github.com/rust-lang/rust/blob/a47555110cf09b3ed59811d9b02235443e76a595/library/std/src/sys/alloc/wasm.rs#L75-L144).
This approach, while effective for browsers, introduces unnecessary
overhead in environments where memory.atomic.wait32 is permitted.
This change provides a similar solution by introducing an opt-in
busy-wait mode for futexes. By making this an optional feature, we avoid
imposing the overhead of busy-waiting in non-browser environments while
ensuring compatibility with browser-based restrictions.
```c
#include <wasi/libc-busywait.h>
/// Enable busywait in futex on current thread.
void __wasilibc_enable_futex_busywait_on_current_thread(void);
```
This change slightly adds some runtime overheads in futex to check if we
should use busywait, but it can be optimized away as long as
`__wasilibc_enable_futex_busywait_on_current_thread` is not used by user
program and LTO is enabled.
commit a3a95960e04e41850b8a41357df39bc324a304fa
Author: Henri Nurmi <henri@nurmi.me>
Date: Thu Jun 19 23:44:58 2025 +0300
wasi-sockets: Add services database and implement getservbyname/getservbyport functions (#532)
This is a follow-up PR for #524 by implementing the following features:
- Embeds a minimal network services database with 17 common protocols,
suggested by @badeend. The database array is a weak symbol allowing
applications to override the default database at link time.
- Updates `getaddrinfo` to resolve named services in the address info.
For example `getaddrinfo("google.com", "https", NULL, &res);`
- Implements the `getservbyname` and `getservbyport` functions. These
functions are implemented using a static variable (`global_serv`), which
holds the returned service entry. This approach is acceptable because
these functions [are defined as not being
thread-safe](https://man.archlinux.org/man/getservbyname.3.en).
~~Additionally, this PR introduces an optional, more comprehensive
services database (`sockets_full_services_db.c`), based on Debian
Bookworm's `/etc/services` file (320 entries). To use this database,
link with the `-lc-full-services-db` flag.~~
commit 48eb92c197058dd6b6ea9f449eb64e50f6f1ffdc
Author: Alex Crichton <alex@alexcrichton.com>
Date: Thu Jun 19 21:30:23 2025 +0200
Refactor how CI works in this repository (#588)
There are a number of changes in this commit aimed at addressing #587
and making it easier to test #586 in CI. Notable changes here are:
* The matrix of what to test is much different from before. One matrix
entry now builds just one target and optionally tests that target.
* The CI matrix ensures that wasi-libc builds on a variety of platforms,
e.g. Windows/macOS/Linux as well as Linux aarch64.
* The CI matrix has one entry for building with an older version of
LLVM. This version was bumped from LLVM to LLVM 11 since LLVM is
installed through `apt-get`, not through downloads any more.
* On Linux LLVM/Clang are downloaded through `apt-get` instead of from
llvm-project binaries to avoid dealing with `libtinfo5` and
dependencies.
* The CI matrix has a test job per-target. This can be expanded/shrunk
as necessary but currently everything is tested with LLVM 16 (as before)
and only on Linux (also as before). The test run is seqeunced to happen
after the build of libc itself.
* The CI matrix has split out V8 headless tests into their own job to
avoid running multiple suites of tests in a single job.
* Installation of LLVM is refactored to a separate action to reduce the
noise in `main.yml`.
* Setting `TARGET_TRIPLE` can now be done through environment variables
as opposed to only through arguments to `make`.
* Handling of `BULITINS_LIB` has improved. Previously the build target
for `libc_so` would modify the compiler's resource directory and this is
updated to use a custom directory in `OBJDIR`.
* Arranging compiler-rt for tests is now done with `-resource-dir`
instead of copying the directory into the system compiler's location.
Overall it's the intention that no amount of testing is lost in this PR.
The goal is to expand things out in such a way that it's much easier to
add one-off tests of wasi-libc in various build configurations and such.
The theory is that this is as "simple" as adding a new matrix entry,
copied from previous ones, customized with various variables and
environment variables to affect the build (e.g. `CFLAGS`).
Closes #587
commit 4720b34e91ccca1b3d4d1df3fd20e6b578898d6a
Author: Dan Gohman <dev@sunfishcode.online>
Date: Mon Jun 2 19:55:39 2025 -0700
Update to musl 1.2.5. (#557)
See the WHATSNEW file for details.
As described on the [musl homepage](https://musl.libc.org/), this also includes the two patches ([1](https://www.openwall.com/lists/musl/2025/02/13/1/1), [2](https://www.openwall.com/lists/musl/2025/02/13/1/2)) fixing CVE-2025-26519. This fixes #577.
commit e0bc5c20cef56f1ad453fda1f4fc28671f96672a
Author: Lukas <33507994+Lukasdoe@users.noreply.github.com>
Date: Tue Jun 3 01:16:25 2025 +0200
clang > 20.1.4 compat: unterminated strings (#584)
clang introduced a new warning (following gcc) for string initialization
to char arrays that do not fit the null terminal.
Introduced here: https://github.com/llvm/llvm-project/pull/137829
Included in LLVM version [LLVM
20.1.4](https://github.com/llvm/llvm-project/releases/tag/llvmorg-20.1.4)+
More detail:
-Wunterminated-string-initialization warns for c string literals that
are written to a buffer too small to include a null terminator. This
warning is also included in -Wextra which is enabled for wasi-libc and
fails compilation due to -Werror.
Possible fixes:
1. deactivate the warning
2. add `__attribute__ ((nonstring))` to the three occurrences where this
is a problem.
Chosen solution: 1.
Since the attribute is not available on older clang versions, it would
trigger another warning there.
(included a small formatting change in the commit - pls ignore)
commit 6b2d6bd4db22cfd56762de24d9af7df04e6c1d46
Author: YAMAMOTO Takashi <yamamoto@midokura.com>
Date: Wed May 14 03:52:10 2025 +0900
Stop complaining on __wasm_extended_const__ (#582)
My motivation is to allow -mcpu=lime1 build with LLVM 20.
Note that extended-const is a part of lime1.
https://github.com/WebAssembly/tool-conventions/blob/main/Lime.md#lime1
cf. https://github.com/WebAssembly/wasi-sdk/pull/527
commit eadb436d5c09f7983c3a687086e5af6b6e9f5510
Author: Yuta Saito <kateinoigakukun@gmail.com>
Date: Fri May 9 23:48:27 2025 +0800
Preserve file timestamps when copying files in the install target (#581)
This change makes it so that the timestamps of installed header files
are only updated when the contents of the header files change. This
change is beneficial for incremental builds of projects depending on
wasi-libc. For example, the Swift project builds wasi-libc as part of
its build process, and this change reduces the number of build products
in the Swift build that are unnecessarily rebuilt.
This is a 2nd attempt of
https://github.com/WebAssembly/wasi-libc/pull/530 but much simpler
thanks to @abrown 's build work
commit e9524a0980b9bb6bb92e87a41ed1055bdda5bb86
Author: Yuta Saito <kateinoigakukun@gmail.com>
Date: Wed Feb 5 01:01:24 2025 +0900
Comment about WASI implementation used in browser testing (#576)
https://github.com/WebAssembly/wasi-libc/pull/563#discussion_r1940291020
commit 525bb2ebf7d2bc41e6cd7fd48f2e5e937c423d2f
Author: mcbarton <matthew.c.barton@hotmail.co.uk>
Date: Tue Feb 4 15:58:43 2025 +0000
Update ADAPTER_URL to reference v29.0.1 (#575)
This PR updates ADAPTER_URL to reference the latest release version
(versions 29.0.1)
commit 08c9059411f890ec47e1ae48c2342a2c78b68c9b
Author: mcbarton <matthew.c.barton@hotmail.co.uk>
Date: Tue Feb 4 13:45:42 2025 +0000
Update WASM_TOOLS_URL to reference v1.224.0 (#574)
This PR updates WASM_TOOLS_URL to reference the latest released version
(version 1.224.0)
commit 7c73575cd40cd5aea1fe97aed2ebc31bc84269da
Author: mcbarton <matthew.c.barton@hotmail.co.uk>
Date: Tue Feb 4 13:45:19 2025 +0000
Update WASMTIME_URL to reference 29.0.01 release (#573)
This PR updates WASMTIME_URL to reference the latest release version
(29.0.1)
commit 51ab1884f810eb3fb35ffaa5da4e31929d015941
Author: mcbarton <matthew.c.barton@hotmail.co.uk>
Date: Tue Feb 4 13:45:05 2025 +0000
Update LIBRT_URL to reference wasi-sdk-25 (#572)
This PR updates LIBRT_URL to reference the latest release version
(wasi-sdk-25).
commit b34d681109fa10076bc7fdc81465eaeecbd0abcd
Author: Yuta Saito <kateinoigakukun@gmail.com>
Date: Tue Feb 4 08:58:41 2025 +0900
test: add browser test harness (#563)
This commit adds a browser test harness to run the tests in the browser.
## Motivation
We are heavily using wasi-libc on browsers but we don't have any test
for the case in wasi-libc. In theory, there should be no behavioral
difference between wasmtime and browsers (as long as WASI
implementations are correct) but browsers have their own limitations in
their Wasm engines. For example, memory.atomic.wait32 is not permitted
on the main thread.
We are working on adding some mitigation for such browser-specific
issues (https://github.com/WebAssembly/wasi-libc/pull/562) and this test
harness will help to validate the fix.
commit abe60626e25a5a4cfc50976f0b57478707019864
Author: mcbarton <matthew.c.barton@hotmail.co.uk>
Date: Mon Feb 3 21:59:29 2025 +0000
[ci] Add Ubuntu arm Github runner (#568)
commit 95122c5204cab0e45cf12220f5455df8b7fa06a5
Author: mcbarton <matthew.c.barton@hotmail.co.uk>
Date: Mon Feb 3 21:03:15 2025 +0000
[ci] Cancel outstanding workflows when new changes are added to PRs (#571)
commit 76702e425056d3f260b0355888f0a16780b3ec93
Author: mcbarton <matthew.c.barton@hotmail.co.uk>
Date: Sun Feb 2 20:57:01 2025 +0000
Pin MacOS Github runner version in ci to MacOS 15 (#565)
Rather than using Macos-latest this makes the ci used a pinned version
of Macos (set to the latest version available). This is so if you happen
to have an issue with the MacOS build you know exactly which version of
MacOS it is running, rather than having to dig into the ci, or Github
runner documentation.
commit 86d142fc9aede67f0023b57e5410efba113bdc17
Author: mcbarton <matthew.c.barton@hotmail.co.uk>
Date: Sun Feb 2 19:22:06 2025 +0000
[ci] Pin Windows runner to Windows 2025 (#566)
Rather than using Windows-latest this PR updates the ci to use a pinned
version of Windows (set to the latest version available). This is so if
you happen to have an issue with the Windows build you know exactly
which version of Windows it is running, rather than having to dig into
the ci, or Github runner documentation.
commit 640c0cfc19a96b099e0791824be5ef0105ce2084
Author: Mike Hommey <mh@glandium.org>
Date: Wed Jan 29 08:26:30 2025 +0900
Adjust Makefile for LLVM trunk (20) as of 2025-01-26 (#564)
https://github.com/llvm/llvm-project/commit/33ad474c45e6d7a0de7bc75e15e27cf6cb9ff895
commit f1c557ce174b3ee2eff6122b2deebf637f6cdaee
Author: Yuta Saito <kateinoigakukun@gmail.com>
Date: Tue Jan 21 08:50:20 2025 +0900
test: enable pthread-related libc-tests (#560)
This change enables the pthread-related tests in the libc-test suite.
The tests are enabled only for the `wasm32-wasip1-threads` target, which
is the only target that supports threads at the moment.
The following pthread tests are still disabled:
- pthread_cancel-points.c
- pthread_cancel.c
- pthread_robust.c
This is a preparative change for
https://github.com/swiftwasm/swift/issues/5598
commit 2504bcd8b77ae72703c6d2d21612ddc49f7b7f0c
Author: Yuta Saito <kateinoigakukun@gmail.com>
Date: Tue Jan 21 08:38:15 2025 +0900
test: fix shebang in run-test.sh (#559)
Follow-up to 2b853ff07903d7dc0af5bdc7b2d3c2e7a6892873
The wrong shebang caused `&>` to be interpreted as a background job
commit 930d16d2856eae484da51a5ea870e2c120d0e76f
Author: Yuta Saito <kateinoigakukun@gmail.com>
Date: Tue Jan 21 06:37:40 2025 +0900
ci: Use Ubuntu 22.04 to ensure compatibility with older LLVM versions (#561)
GitHub Actions is migrating ubuntu-latest to Ubuntu 24.04, which no
longer provides the libtinfo5 package. Since older LLVM versions depend
on libtinfo5 and do not offer pre-built binaries for recent Ubuntu
versions, we explicitly specify ubuntu-22.04 in the workflow to maintain
compatibility.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/w/wasi-libc.png){kind=link}