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.
* Update wasi-libc to latest HEAD
This pulls in a variety of changes, many of them related to enabling
threads in wasi-libc. There may be more changes necessary before
releasing a prelease version of wasi-sdk that supports the new
`wasm32-wasi-threads` target, but this should get the majority of them.
* review: incorporate WebAssembly/wasi-libc#324
* Add a variation of wasi-sdk.cmake for pthread-using apps
* Install wasi-sdk-pthread.cmake
* Build wasi-libc with THREAD_MODEL=posix as well
* wasi-sdk-pthread.cmake: target rename to wasm32-wasi-threads
after https://github.com/WebAssembly/wasi-libc/pull/381
* Update llvm-project to the latest release/15.x
This pulls in the `__heap_end` symbol, which fixes the issue discussed
in https://github.com/WebAssembly/wasi-libc/pull/377.
* Update to the official 15.0.7 release.
The version 11.0 is chosen because Apple seems providing
support for two previous releases.
(As of writing this, the latest is 13.)
REVISIT: as we don't need any brand-new OS features, it
might make more sense to specify even older version.
This might explain the following error i've seen with wasi-sdk-17.0
release binary on macos-11.0:
```
Run Build Command(s):/usr/bin/make -f Makefile cmTC_254ef/fast && /Applications/Xcode_13.2.1.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTC_254ef.dir/build.make CMakeFiles/cmTC_254ef.dir/build
Building C object CMakeFiles/cmTC_254ef.dir/testCCompiler.c.obj
/Users/runner/work/toywasm/toywasm/.wasi-sdk-17.0/bin/clang -o CMakeFiles/cmTC_254ef.dir/testCCompiler.c.obj -c /Users/runner/work/toywasm/toywasm/build.wasm/CMakeFiles/CMakeScratch/TryCompile-aWXHXM/testCCompiler.c
dyld: Symbol not found: __ZTTNSt3__114basic_ifstreamIcNS_11char_traitsIcEEEE
Referenced from: /Users/runner/work/toywasm/toywasm/.wasi-sdk-17.0/bin/clang (which was built for Mac OS X 12.0)
Expected in: /usr/lib/libc++.1.dylib
in /Users/runner/work/toywasm/toywasm/.wasi-sdk-17.0/bin/clang
make[1]: *** [CMakeFiles/cmTC_254ef.dir/testCCompiler.c.obj] Abort trap: 6
make: *** [cmTC_254ef/fast] Error 2
```
References:
https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html
Update to wasi-libc a1c7c2c7a4b2813c6f67bd2ef6e0f430d31cebad
- Don't use sbrk(0) to determine the initial heap size (WebAssembly/wasi-libc#377)
- Fix more headers to avoid depending on `max_align_t` (WebAssembly/wasi-libc#375)
- Use `ENOENT` rather than `ENOTCAPABLE` for missing preopens. (WebAssembly/wasi-libc#370)
- Adjust Makefile for LLVM trunk (16) as of 2022-11-08 (WebAssembly/wasi-libc#344)
These dependencies are not needed in wasi-sdk, and if they're enabled,
the msys2 dll depenndencies will leak into build products. Also
statically links libstdc++, required for the windows build.
Andrew Brown
Casper Beyer
Alex Crichton
Cheng Shao
YAMAMOTO Takashi
Anuraag Agrawal
Jo Shields
Catherine
Johannes Lundberg
Dan Gohman
Cheng Shao
Ryan Lopopolo