In componentize-py Joel's building custom wasi-sdk binaries for more
Linux compat which is what maturin, the build tool use there, desires. I
don't think there's a concrete reason to have a higher Linux version
here, so let's lower it in wasi-sdk itself.
This commit switches the build container from Ubuntu 20.04 (glibc 2.31)
to AlmaLinux 8 (glibc 2.28). The AlmaLinux container is what Wasmtime
uses, for example, and has supported security updates to 2029 and is I
believe intended to be used for purposes such as this.
This commit updates the build of the `wasm32-wasip2` target to always
pass `-fPIC` to compilation of wasi-libc. This notably enables using
`libc.a` in dynamic linking situations instead of being forced to use
`libc.so`. While many applications likely want to use `libc.so` I've
found it more flexible if objects are compatible with as many builds as
possible. This will enable, for example, building shared libraries in
Rust by default since Rust only ships `libc.a`, not `libc.so`, in the
pre-built sysroot. This behavior additionally matches the Rust
`wasm32-wasip2` target where `-fPIC` is enabled by default there.
* Provide flags for emitting the standard exception-handling
instructions.
* More further explain what flags are doing.
* Show a sample program that can be compiled both ways.
* Delegate running in a runtime to various runtimes, so remove the "run
the program" documentation here.
* Remove `wasm-opt` documentation since it's now documented how to emit
the standard instructions directly with LLVM.
This bit me while releasing wasi-sdk-26/27 because while I tried to get
both builds going at once they overlapped in their key meaning that they
had to progress one-at-a-time. This uses `github.ref` instead of the PR
number which I think should be more robust in situations like this.
Add a cmake option WASI_SDK_CPU_CFLAGS to specify CFLAGS to control wasm
features to enable/disable.
Make the default `-mcpu=lime1`.
Comparing to the default "generic" target of the recent llvm, this
effectively
* disables reference-types and bulk-memory (enable their partial
counterparts instead)
* enables extended-const
Note: as of writing this, a few popular runtimes, including wasm3 and
wasm-micro-runtime,
don't support extented-const yet.
Note: regardless of this, wasi-libc enables necessary features for
certain files. (bulk-memory and exception-handling)
cf. https://github.com/WebAssembly/wasi-sdk/issues/525
References:
https://github.com/WebAssembly/tool-conventions/blob/main/Lime.mdhttps://github.com/bytecodealliance/wasm-micro-runtime/issues/4272
This commit enables thread support in libc++ for all thread models,
enabling C++ applications that use threading APIs like `<atomic>` but do
not spawn threads (e.g. Clang) to be built with minimal changes.
Fixes#546.
Depends on WebAssembly/wasi-libc#602.
Update from LLVM 20.1.1 to 20.1.8. This release contains various bug
fixes and notably for wasi-sdk includes llvm/llvm-project#146574, which
fixes inline asm vector operands.
`wasi-sdk` releases have always been a bit ad hoc, but after discussing
#536 we all agreed some regularity would be helpful; let's see what we
think of a 3-month cadence.
This change allows us to have per-target libclang_rt.* libraries instead
of per-OS. This is particularly required for w/threads and wo/threads
targets, whose rt libraries could be incompatible even with the same OS
string.
This change starts building `compiler-rt` for w/threads and wo/threads
separately, so that we can enable thread-related features for p1-threads
target for building upcoming ASan clang_rt libraries. Also
`COMPILER_RT_OS_DIR` is not set anymore as it's unused when
`LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is enabled.
This PR can fix:
5 warnings found (use docker --debug to expand):
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 23)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 24)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 25)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 26)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 27)
Hi! I added `WASI_ARCH=arm64` command for the arm64 package version to
the installation command’s comment. I thought this would make the
command more clear.
* Pin CI runner images to explicit versions
CI is run infrequently enough on this repository that there's a
nontrivial chance that GitHub updates the definition of `ubuntu-latest`
for example between two CI runs. This can be confusing for contributors
as PRs seemingly break CI when in reality they have nothing to do with
the breakage and it's due to the image changing.
This PR pins all images to the definition of `*-latest` at this time.
The one exception is that one builder was pinned to 22.04 and I'm going
to update it to 24.04 here and see if I can't fix CI issues that come up.
This'll require explicit PRs to update these images in the future, but
hopefully that's only once every few ~years so not too much of a burden.
* Try not custom-installing clang 18
* Try to fix CI issue
* Fix CI again (attempt)
* Further try to fix CI
* Another fix for CI
Surely if I keep making commits that say "another fix" eventually I'll
run out of fixes. Surely, right? I'd put this in limerick form to be
more amusing if someone comes to read this but I'm not clever enough to
do that, so instead I'll just abruptly
* Update wasm-component-ld
Pulls in a fix for bytecodealliance/wasmtime#10058 in the adapters that
are used by default.
* Update wasmtime installed in CI
* Downgrade the build-only-sysroot check step
Looks like this is failing on Ubuntu 24.04, the new default of
`ubuntu-latest`, so downgrade it to have it get fixed in a separate PR.
* Try downgrading Wasmtime version again
* Update base Linux images to Ubuntu 20.04
* Update Wasmtime back to 29
* Update to the latest wasi-libc.
This contains two significant changes:
- Implement a stub pthreads library for `THREAD_MODEL=single` (#518)
- Initial FTS support (#522)
* Update to the latest wasi-libc with build fix
This update includes a build fix for shared library builds.
---------
Co-authored-by: Dan Gohman <dev@sunfishcode.online>
* Add missing architecture URL part to the installation script
* Remove unnecessary `export`s from installation instructions
* Fix missing $ sign in export
* Add `WASI_OS` as new parameter to use & install scripts in README
---------
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
There is an option to compile debug information to separate file. It's supported in Clang via -gsplit-dwarf to generate dwo files but we need llvm-dwp tool to combine them into single dwp file supported by Chrome DWARF extension https://developer.chrome.com/blog/faster-wasm-debugging
* Add back `VERSION` file to release tarballs
Make sure it makes its way into the sysroot tarball and then copy it
from the sysroot location to the top of the sdk tarball as well.
Closes#471
* Fix how `VERSION` is installed
This commit adds a test and matrix entry to CI which asserts that the
sysroot can be built to run tests using a stock Clang compiler found on
the system. This fixes a few minor issues as well in developing this.
This additionally refactors CI a bit to move shared steps amongst jobs
into separate composite actions in this repository to avoid duplication
across jobs.
Alex Crichton
Tim Chevalier
Catherine
YAMAMOTO Takashi
Dan Gohman
Andrew Brown
Yuta Saito
mcbarton
Timothy McCallum
Am K
Masashi Yoshimura
Carlo Cabrera
Andrii Rublov
Roman Kolesnikov
SingleAccretion