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>
^~~~~~~~~
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.
* Make build work on Windows
* re-enable windows build workflow
* fix make check
* fix tar_from_installation.sh and dist target
* Review fixups
* No -j4 on Windows
* Get rid of -j4 everywhere in Makefile
* build: put artifacts into dist/. workflow: upload contents of dist/.
* review feedback
* CI workflow: add comment explaining artifact name
* checkout action to v1
* typo fix
This installs unqualified `nm`, `ar`, and other symlinks, additional
tools including `llvm-objdump` and `llvm-objcopy`, and additional clang
tools such as `clang-format` and `clang-tidy`.
libc++ and libc++abi have config variables which can be used to enable
multi-arch installation paths. Use those instead of moving the libraries
after they are installed.
This renames /opt/wasi/share/sysroot to /opt/wasi/share/wasi-sysroot.
If the user selects an alternate prefix, this allows wasi-sysroot to
coexist with other packages with less risk of namespace collision. For
example, if the user uses a prefix of /usr/local, this avoids using
/usr/local/share/sysroot, which is fairly generic, and uses
/usr/local/share/wasi-sysroot, which more clearly indicates its purpose.
The wasi-libc update here brings numerous bug fixes and minor changes,
and __wasilibc_rmfileat has been renamed to __wasilibc_unlinkat.
The only WebAssembly-relevant patch in the LLVM 8.0.1 update here is
4b1712f7, a fix for using /dev/null as the output file.
Libc++abi's verbose terminate handler is only useful when exceptions are
enabled. Disabling it removes a few hundred thousand bytes from many C++
programs.