When running Git commands inside this Docker container (i.e., commands
that the `version.py` script needs for determining version information),
the Docker build would run into issues like:
```
fatal: detected dubious ownership in repository at '/workspace'
To add an exception for this directory, call:
git config --global --add safe.directory /workspace
```
This is due to an extra Git check that detects that the Docker user is
not the same one who owns the `.git` directory of this project. After
looking into this, the best solution the internet has to offer is to
thread the current user's UID and GID through the Docker image (i.e.,
the new `builder` user) and then `docker run --user ...`. This both
avoids the Git check but also seems to be considered a best practice in
some circles (?).
As noted in #372, some users may need to identify which version of
wasi-sdk they are using after it has been downloaded. There are many
ways to solve this, but the one I chose here is to dump the wasi-sdk
version into a `VERSION` file and follow that up with several dependency
versions that may be helpful to note when troubleshooting. Ideally
someone could paste the contents of that file when filing a bug. If we
adopt this approach, this fixes#372.
In the past, I've had trouble keeping the current set of version scripts
to correctly output the version, especially in light of how we append
Git suffixes for a non-tagged commit and dirty state. This change
replaces those scripts with a single Python one which, though much more
wordy than the previous one, may be easier for contributors to read and
modify. The original scripts relied on Perl; this one relies on Python,
which seems like a fair exchange. Having a single script also makes it
easier to solve #372.
This test looks to be asserting that `getrandom` never returns 256
consecutive zeros, but the way it's asserting that is summing up the
bytes and asserting the sum is nonzero. Due to this being a signed
addition, however, it's possible for the bytes to be nonzero and still
trigger the assert. Locally running this test in a loop took 30 or so
seconds before it triggered a failure.
I've updated the test to instead hunt for any entry which is not equal
to zero and then assert that something is not zero.
* Explicitly set LIBCXXABI_USE_LLVM_UNWINDER off
Clang trunk has recently turned it on, and also now fails the build when
libunwind is not built at the same time.
* Bump LLVM to 18.1.0
---------
Co-authored-by: Mike Hommey <mh@glandium.org>
Currently the `bin` directory installed by wasi-sdk is not currently
suitable for putting in `$PATH` in all cases because it can shadow a
system-installed `clang` executable which is intended for native
binaries. For Linux distributions with gcc-based cross-compilers I've
often seen the pattern where they're installed as `$target-gcc` and so
I've taken a leaf out of their books to do that here as well.
This commit adds, currently alongside the preexisting `clang`
executable, target-prefixed executables such as `wasm32-wasi-clang` and
`wasm32-wasi-clang++`. These executables are symlinks to the `clang`
executable itself in the same manner that `clang++` is a symlink to
`clang` itself.
I'll also note that this doesn't fix the problem of "add the wasi-sdk
bin dir to PATH" because `clang` and other prominent executables are
still there. My hope though is that this opens up a future refactoring
for doing so.
* Refactor installation of wasmtime/wasm-tools on CI
We've got official actions for installation Wasmtime and wasm-tools in
the bytecodealliance organization which should help make this
installation step a bit more readable.
* Change the directory of the adapter
* Update descriptions
* Start renaming preview1 to p1 and preview2 to p2
This commit is a reflection of WebAssembly/wasi-libc#478 into this
repository where a few changes are happening:
* A new `wasm32-wasip1` sysroot is prepared matching `wasm32-wasi`
* A new `wasm32-wasip1-threads` sysroot is prepared matching `wasm32-wasi-threads`
* The `wasm32-wasi-preview2` target is renamed `wasm32-wasip2`
I've done a bit of makefile refactoring to deduplicate things a bit now
that there's a number of targets being built.
The long-term goal would be to remove the `wasm32-wasi` and
`wasm32-wasip1-threads` targets, but that's not proposed just yet at
this time.
* Use $(CLANG_VERSION) instead of hardcoding
As of LLVM 17, which includes https://reviews.llvm.org/D152168, libcxx has
combined the old `_LIBCPP_HAS_NO_FILESYSTEM_LIBRARY` and
`_LIBCPP_HAS_NO_FSTREAM` preprocessor symbols into a single
`_LIBCPP_HAS_NO_FILESYSTEM` symbol, which means there's no longer any way to
enable `<fstream>` without enabling `<filesystem>`.
The solution is to set `-DLIBCXX_ENABLE_FILESYSTEM:BOOL=ON` and update
`wasi-libc`, which includes stubs for the functions required by libcxx's
`<filesystem>` implementation.
Fixes#373
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
* build and test `wasm32-wasi-preview2` target
This updates `wasi-libc` to include
https://github.com/WebAssembly/wasi-libc/pull/457, which adds preliminary
support for the new `wasm32-wasi-preview2` target.
It also adds support for testing the new target using Wasmtime 16.0.0 and
`wit-component`. Note that Wasmtime produces different output when reporting
errors for Preview 2 components than it does for Preview 1 modules, so I've
added a few .expected files specific to Preview 2.
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
* test all three targets
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
---------
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
```
error: Server does not allow request for unadvertised object f992bcc08219edb283d2ab31dd3871a4a0e8220e
fatal: Fetched in submodule path 'src/config', but it did not contain f992bcc08219edb283d2ab31dd3871a4a0e8220e. Direct fetching of that commit failed.
```
FreeBSD (like MacOS) does not support the `-executable` argument for
`find`. This commit checks if the OS is FreeBSD, and if so, uses the
same workaround as already in place on MacOS.
In #321, some OSX-specific `Makefile` additions to `LLVM_CMAKE_FLAGS`
were skipped unless `make` is run on a Darwin OS. This allowed building
wasi-sdk for aarch64. But, as reported in #336, this also broke
arm64/x86_64 universal binaries that are built during CI.
The reason for this is that CI's `main.yml` overrides `LLVM_CMAKE_FLAGS`
to add caching but `make` will not append to a variable set on the
command line. This changes uses the `override` keyword to append to
such a variable, as suggested [here].
[here]: https://www.gnu.org/software/make/manual/html_node/Override-Directive.html
This changes the front-page documentation to:
- use out-of-line links in more places
- mention the need for `libclang_rt.builtins-wasm32.a` when using
standard Clang
- mention how to use a `wasi-libc` sysroot
- explain the experimental status of `wasm32-wasi-threads
It looks like some macOS-specific CMake options to LLVM end up forcing
an x86_64 build of some blake3 intrinsics (or something like that) which
causes the build to fail on AArch64 Linux, for example. I found, though,
that when removing these options it was then possible to build a
toolchain for AArch64 Linux.
This patch enables using latest version of wasmtime for testing. This
should also make it possible to running tests for wasm32-wasi-threads
in the future.
When testing out these scripts on a fork, I realized that it was more
convenient to use a single environment variable (e.g.,
`GITHUB_API_URL=... ci/draft-release.sh`) to change some of the script's
input parameters.
This change refactors the script logic that checks if a workflow in fact
built the commit matching our release tag out into a separate script.
This is mainly an improvement in clarity.
This commit passes through `EXTRA_CFLAGS` to the libcxx build, along
with `EXTRA_CXXFLAGS`. This models after the pattern in `wasi-libc` for
passing these flags to thread more flags through.
WebAssembly/wasi-libc#403 fixed an issue with `a_barrier` that should be
included in the next release of wasi-sdk. This change updates wasi-libc
to the latest `HEAD` of `main` to include it.
Sometimes a C codebase might have the odd file written in Assembly. We should force the use of Clang as the assembly compiler for these cases (which it is perfectly capable of doing), and make sure we pass on the WASI compiler triple the same way we do for C and C++.
* llvm-project: update to 16.0.0 release
This changes updates the `src/llvm-project` submodule to the `HEAD` of
`release/16.x`, the same commit used to [release] the LLVM 16.0.0
binaries.
[release]: https://github.com/llvm/llvm-project/releases/tag/llvmorg-16.0.0
* fix: use only Clang's major version in install prefix
Due to [a change] in LLVM, Clang will expect to find the
`libclang_rt.builtins-wasm32.a` file in a path that only contains the
major version (`16`) instead of the entire version (`16.0.0`) as was
previously the case. This change modifies the `CMAKE_INSTALL_PREFIX` to
use Clang's major version only.
[a change]: https://reviews.llvm.org/D125860
* review: only use `llvm_version_major.sh`
Since the `Makefile` can get by with only knowing Clang's major version,
this change removes `llvm_version.sh` and sets `CLANG_VERSION` to use
only the major part.
This change switches the MacOS build to target 10.12, an older version
than currently supported. This would close#127. @sbc100 mentions that
this is the setting used by Emscripten and related projects.
Previously, the release process for wasi-sdk was undocumented and
manual. The `RELEASING.md` document in this commit describes the steps
necessary to publish a new version of `wasi-sdk` as a GitHub release and
provides helpful scripts to automate some of the steps.
With this in place, a future change could add a workflow trigger that
allows running the steps automatically in GitHub actions. Keeping the
steps as scripts in the repository, however, allows developers to re-run
steps themselves in the (likely) case that something goes awry.
Andrew Brown
Mike Hommey
Alex Crichton
Andy Li
Changqing Jing
Brett Cannon
Joel Dice
YAMAMOTO Takashi
liang.he
Arvid Norlander
Kian Cross
Michael Lill
Anuraag Agrawal
Casper Beyer
Cheng Shao
Jo Shields
Catherine
Johannes Lundberg