wasi-sdk: macOS release binaries not able to create executables
Given these env variables:
export PATH="${PROJECT}/wasi-sdk-10.0/bin:$PATH"
export WASI_SYSROOT="${PROJECT}/wasi-sdk-10.0/share/wasi-sysroot"
clang --target=wasm32-wasi --sysroot="${WASI_SYSROOT}" ...
I then see configure: error: C compiler cannot create executables
.
- ./configure --prefix=/…/wasm-build --with-sysroot=/…/wasi-sdk-10.0/share/wasi-sysroot --host=wasm32-wasi --disable-ssp --disable-shared
checking build system type… i386-apple-darwin19.5.0
checking host system type… wasm32-unknown-wasi
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for wasm32-wasi-strip… llvm-strip
checking for a thread-safe mkdir -p… build-aux/install-sh -c -d
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking whether make supports nested variables… yes
checking whether UID ‘501’ is supported by ustar format… yes
checking whether GID ‘20’ is supported by ustar format… yes
checking how to create a ustar tar archive… gnutar
checking whether make supports nested variables… (cached) yes
checking whether to enable maintainer-specific portions of Makefiles… no
checking whether make supports the include directive… yes (GNU style)
checking for wasm32-wasi-gcc… clang
checking whether the C compiler works… no
configure: error: in
/.../': configure: error: C compiler cannot create executables See
config.log’ for more details
I am able to make a sysroot
myself inside a checked out wasi-sdk
repo with make install INSTALL_DIR="${PROJECT}/sysroot/"
and I can use it to compile the same project (after I’ve downloaded and placed libclang_rt.builtins-wasm32-wasi-10.0.tar.gz
into my llvm
installation inside homebrew). However, I’d like to take advantage of the pre-compiled binaries + sysroots if at all possible because I’ve run into a problem too many times with one machine having a different version of llvm installed, etc.
One key difference I notice when using the version I compiled myself is it says it’s build system type is x86_64-apple-darwin19.5.0
.
I am using macOS 10.15.5 with the latest homebrew and llvm
10.0.0_3
.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 28 (17 by maintainers)
Commits related to this issue
- Make the `__original_main` definition weak, fixing -flto. (#138) — committed to kildom/clang-wasi-port by sunfishcode 5 years ago
- Roll wasi-libc to include snapshot1 (#84) This brings in the following changes: f645f49 Update signal macros after upgrade to snapshot1 (#144) 8b3266d github actions: pin checkout action to v1 (#... — committed to alexcrichton/wasi-sdk by sbc100 5 years ago
You need to install that file (eventually, the Homebrew formula will install it along with
llvm
but it is not the case yet).See https://github.com/jedisct1/libclang_rt.builtins-wasm32.a
Breaking changes happened to
wasi-sdk
,wasi
and to various runtimes since the release.The
stable
branch doesn’t change the API and doesn’t introduce new features, but was introduced to backport performance improvements, and to keep up with external breaking changes, as well as add support for new compilers (such as Visual Studio 2019 that was also released since).Wait, are you trying to compile
libsodium
?The
config.log
file may tell you more about why executables cannot be created.But macOS binaries available for download here are not notarized, so they cannot be used on Catalina if you download them using a web browser, or anything quarantining untrusted downloads.
A possible workaround is to download them using
curl
instead of a web browser.But if you are using Homebrew, you really don’t need a second installation of LLVM, especially since LLVM packages in Homebrew are always up to date.
The wasi-sdk
downloads
include a precompiledwasi-sysroot
. This, in addition to the precompiled builtins, is all you need if you already installedllvm
usinghomebrew
.I started to work on a Homebrew package to add these dependencies. A package for the wasi sysroot is pretty straightforward, but for the builtins, I couldn’t figure out how to cleanly install them into another package’s (llvm) path.