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.
* Require that the compiler is Clang, for example gcc and msvc cannot
compile to WebAssembly.
* Require that the Clang version is above the minimum threshold. Unsure
what the minimum threshold is at this time so I've set it to 18.0.0
This commit fixes a bug from the cmake migration where tests were not
actually testing the correct target. Object files were compiled with the
right options but the link step was missing both `--target` and
`-pthread` which caused everything to accidentally be tested as
`wasm32-wasi`. When fixing this one test was needed to have its stderr
updated because the component output of `wasm32-wasip2` is slightly
different. A timeout was additionally added because without `-pthread`
at the link step some tests infinitely ran which made debugging
difficult.
This is an attempt to fix CI errors where the `config` submodule is now
located on a commit further than 32 commits behind the main branch
(presumably).
To include https://github.com/WebAssembly/wasi-libc/pull/517,
which is necessary to avoid modifying host compiler's resource
directory.
At least on my environment (macOS if it matters), without the above
mentioned fix, gmake tries to create the directory for wasi compiler-rt
during wasi-libc build. I'm not sure why it didn't happen for others.
cf. https://github.com/WebAssembly/wasi-sdk/pull/445
* Add LTO build of wasi-libc
* Add LTO build of libc++
* Update wasi-libc (to include the LTO support)
* Add a comment about /llvm-lto/${llvm_version} convention
* Use separate targets for wasi-libc with and without lto
A downside: this makes four more copies of wasi-libc source tree.
* Make LTO build optional
* Retire clang_version
Note: this makes the "install" target install the compiler rt
into the compiler's runtime directory. IMO, it's what "install" is
supposed to do. If you want to avoid modifing the runtime directory
for some reasons, you can still do "dist" without "install".
* wasi-sdk-sysroot.cmake: Avoid modifying things out of CMAKE_INSTALL_PREFIX
* wasi-sdk-sysroot.cmake: control the resource-dir modification by a cmake option
* Use MSVC for the Windows toolchain instead of MinGW
Explicitly use MSVC to avoid the runtime dependencies that the default
toolchain CMake is using is bringing in.
Closes#454
* Update .github/workflows/main.yml
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
* Specify MinSizeRel in `build.sh`
Looks like MSVC defaults to "Debug" instead of an empty string to so the
default logic which works for other compilers isn't kicking in here.
* Don't persist ccache stats across runs
* Move zeroing
---------
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
This command is generally not included in toolchain files. It is used in
project configuration files that will consume the toolchain file. Also,
such a low value triggers warnings, support for <3.5.0 is being removed
from CMake.
I noticed in a [recent build] that the cache size for Windows is quite
large at 500M. That might be related to switching to MSVC, I'm not sure,
but something else I've realized is that as-configured wasi-sdk will
continuously grow the cache over time and it won't ever get trimmed
until we hit github actions limits. This is because the cache is
restored from an older version, then appended to with the current
build, then saved again. That theoretically means that each builder
could make up to a 5G cache which is a bit too large.
This commit adds an extra step that removes all objects older than 1d to
ensure that older builds eventually get cleaned out of the cache. GitHub
Actions should then still delete older caches pretty regularly but each
individual cache should be bounded still.
[recent build]: https://github.com/WebAssembly/wasi-sdk/actions/runs/10045872592/job/27764084758?pr=456
* Refactor handling env vars in CI build
This commit updates the handling of various environment variables to
centralize them in one location in `main.yml` as part of CI
configuration. This removes a few custom-named variables in favor of
using explicitly-listed env vars. Additionally this moves some env var
management from the CI container files to the github actions config as
well to keep everything in one place ideally.
* Add some more comments about where configuration comes in
* Add a CI check for testing toolchains as-distributed
One aspect of testing lost in the CMake-based migration is the ability
to test the toolchains as distributed in release artifacts. Tests use
`--sysroot` and `-resource-dir` (soon) to customize how the host
compiler runs but this means that it would be possible to regress the
default sysroot theoretically. To rectify this situation this commit
adds a new CI test which uses the release artifacts of previous steps to
build a `wasi-sdk-*.tar.gz` tarball which is then extracted and tested
as-is. A new flag was added to the cmake configuration to avoid
depending on fresh sysroot libraries for tests and instead test the host
toolchain.
* Fix version.py script running
* Fix artifact download
* Add ninja
* Update submodules in new test job
* Only add extra options for libcxx build
Otherwise the test directory seems like it inherits these options which
isn't desired when testing the host toolchain.
This commit updates the building of the wasi-sdk sysroot to leverage the
`-resource-dir` argument from Clang to avoid modifying the host
compiler's sysroot with compiler-rt things. This should help improve the
experience of building a standalone sysroot with whatever host Clang is
on the system.
Closes#444
This includes support for a new `--component-type` option, which allows passing
one or more component types as WIT files rather than (or in addition to) object
files, which can be preferable when such files must be stored in source control.
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Catherine
Dan Gohman
Andrew Brown
Alex Crichton
Yuta Saito
YAMAMOTO Takashi
mcbarton
Timothy McCallum
Am K
Masashi Yoshimura
Carlo Cabrera
Andrii Rublov
Roman Kolesnikov
SingleAccretion
Matt McCormick
Joel Dice