- Fix utimensat to avoid passing uninitialized values into WASI calls.
- Optimize memcpy etc. using bulk-memory
- Update to musl 1.2.3.
- Fix `gettimeofday` to correctly handle a null argument.
- Remove support for `__original_main`. (#295)
This is the new method to build runtimes as of LLVM 12, and the previous
standalone method is deprecated since LLVM 14 and unsupported since
LLVM 15 (6f17768e11)
Building libcxx and libcxxabi in one go simplifies the setup necessary
as:
- tests CMakeLists.txt have some wrong dependencies which would need
to be worked around.
- LIBCXXABI_LIBCXX_INCLUDES is not recognized when building separately
and passing -I paths via the command line yields msys path munging
problems on Windows.
This effectively drops support for LLVM 11 and older.
* Update to the latest wasi-libc and LLVM 14.0.3
This updates:
- llvm-project to the llvmorg-14.0.3 tag
- wasi-libc to the current main branch
- config to the current master branch
* Update wasi-libc to pick up WebAssembly/wasi-libc#289.
The virtual-environments documents are at: https://github.com/actions/virtual-environments .
Currently, the `windows-latest` == `windows-2022`
We currently are using `Microsoft Visual Studio\2019` installed with `windows-2019` and that not installed in `windows-2022`
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
When building wasi-sdk locally, we doesn't need so verbose output that not easily distinguish
the error command from the normal command. So refactoring -v option into workflow scripts
With the following building commands:
```
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64
set MSYS2_PATH_TYPE=inherit
set MSYSTEM=MINGW32
set CC=cl
set CXX=cl
set "HOME=%CD%"
bash.exe --login -c "make package"
bash.exe --login -c "make check"
cmd /k
```
Fixes following error:
c:\wasi-sdk\bin\clang++.exe --target=wasm32-wasi -DNDEBUG -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -Iinclude/c++build -fdebug-prefix-map=C:\work\wasi-sdk=wasisdk;\v13.5g73d30af917c4 --sysroot=c;C:\CI-Tools\msys64\wasi-sdk\share\wasi-sysroot -fPIC -DLIBCXX_BUILDING_LIBCXXABI -IC:/work/wasi-sdk/build/libcxx/include/c++/v1 -std=c++20 -MD -MT src/CMakeFiles/cxx_static.dir/regex.cpp.obj -MF src\CMakeFiles\cxx_static.dir\regex.cpp.obj.d -o src/CMakeFiles/cxx_static.dir/regex.cpp.obj -c C:/work/wasi-sdk/src/llvm-project/libcxx/src/regex.cpp
In file included from C:/work/wasi-sdk/src/llvm-project/libcxx/src/regex.cpp:9:
In file included from C:/work/wasi-sdk/build/libcxx/include/c++/v1\regex:766:
In file included from C:/work/wasi-sdk/build/libcxx/include/c++/v1\__debug:14:
In file included from C:/work/wasi-sdk/build/libcxx/include/c++/v1\iosfwd:98:
C:/work/wasi-sdk/build/libcxx/include/c++/v1\wchar.h:119:15: fatal error: 'wchar.h' file not found
#include_next <wchar.h>
^~~~~~~~~
It appears I accidentally merged in a git submodule diff in #197
which reverted the LLVM, wasi-libc, and config updates. Revert
that change, updating wasi-sdk again to LLVM 13.0 and the latest
wasi-libc and config.
It appears newer LLVM releases need a newer version of Python, and
Xenial is quite old at this point, there being two LTS releases newer
it at this time.
This makes use of https://reviews.llvm.org/D76653, which is in clang 11
and newer, to fix#53. With this, clang can find the sysroot relative to
its own path.
Fixes#58.
* fix deb build:
change makefile and deb_from_installation to invoke it with the new
build directory (changed in #143).
deb_from_installation will exit 0 if dpkg-deb missing so we dont try
to run it as part of `make package` on non-deb systems, but other errors
should cause the makefile to fail, which should catch regressions like
this sooner in the future.
* thank you fgsch for style fix
* Update how wasi-sdk uses cmake
Change `CMAKE_SYSTEM_NAME` to `WASI`, use a `CMAKE_MODULE_PATH`,
remove `CACHE` usage, and fix the compiler autodetection code so that
the "compiler works" hacks are no longer needed, following the advice in
[this comment](https://gitlab.kitware.com/cmake/cmake/-/issues/19223#note_567327).
This is hopefully a step towards re-submitting WASI support to upstream cmake.
* Add --sysroot to compiler-rt's C flags.
This ensures that it finds the built sysroot when testing whether the C
compiler works.
* Fixes.
* Use the just-built ar rather than the host ar.
* Use -DCMAKE_C_COMPILER_WORKS=ON instead of stubbing out archive files.
* Use -DCMAKE_CXX_COMPILER_WORKS=ON too.
* Restore the `--sysroot` argument when building compiler-rt.
compiler-rt depends on some libc headers, so it needs a sysroot.
* Add sysroot arguments for libc++ and libc++abi too.
* Also set CMAKE_AR.
It appears with the removal of the AR checks cmake is no longer
autodetecting CMAKE_AR, so set it explicitly.
* Remove --no-threads from wasi-sdk.cmake.
It was added to work around this bug:
https://bugs.llvm.org/show_bug.cgi?id=41508
which was fixed in LLVM 9.0.
* Remove LLVM 8.0 workarounds.
We still build with the `/opt/wasi-sdk` prefix but we don't actually
install into that directory. Instead we install into `build/install`.
This means you don't need to run `sudo make` and you don't end up with
a all the build output being owned by root.
The main different is that this requires the `--sysroot` flag when
running clang to build the testsuite.
* Add a basic testcase for emulated signals.
* Add a testcase for raise(SIGABRT).
* Fix style.
* Actually use all of the C-standard-required signals.
* Update expected stderr.
* Use the right version of this test file.
Co-authored-by: Pat Hickey <pat@moreproductive.org>
The update to LLVM 10.x was done in #108 but the submodule branch was
not updated.
As discussed in #136, the branch line is now removed to avoid such
problems.
Ryan Lopopolo
Dan Gohman
Cheng Shao
Mike Hommey
Greg. A
Vladislav Nepogodin
John Ericson
Yonggang Luo
gautric
Brett Cannon
Mike Hommey
Pat Hickey
Vladimir Vukicevic
Dan Gohman
Sam Clegg
Orestis Floros
Steve Manuel