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.
* 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
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
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.
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.
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.
Andrew Brown
Catherine
YAMAMOTO Takashi
Cheng Shao
Dan Gohman
Mike Hommey
Vladislav Nepogodin
John Ericson
Yonggang Luo
Mike Hommey
Pat Hickey
Dan Gohman
Sam Clegg
Vladimir Vukicevic
Alex Crichton
Yury Delendik