Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to compile for wasm32-wasi using standalone sysroot: "no available targets are compatible" #172

Closed
anp opened this issue Feb 3, 2021 · 5 comments

Comments

@anp
Copy link

anp commented Feb 3, 2021

I'm trying out the SDK and have downloaded only the sysroot. It's extracted to /Users/adam/code/wasi-sysroot, but when I pass it to clang I get an error:

❯ clang --target=wasm32-wasi --sysroot=/Users/adam/code/wasi-sysroot main.cc
error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-wasi"'
1 error generated.

The contents of main.cc don't seem to matter but the error above came from a file with int main() {} as its contents.

I see that your release tarballs are using clang 11, whereas the xcode tools seem to have given me 12:

❯ clang --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: arm64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Maybe that's the issue?

This error was one of several others I was seeing in the larger project from which I pulled this command. The contents of the sysroot seem valid on disk, as the other errors disappeared when I began passing --sysroot=....

@sbc100
Copy link
Member

sbc100 commented Feb 3, 2021

It looks like perhaps your clang binary doesn't have support for WebAssembly. Although then I would expect to see an error message more like this:

clang --target=foo hello.c
error: unknown target triple 'foo', please use -triple or -arch

You can see the targets that are included by running llc --version. For example on my system:

$ llc --version
LLVM (http://llvm.org/):
  LLVM version 11.0.1
  
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: broadwell

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_32 - AArch64 (little endian ILP32)
    aarch64_be - AArch64 (big endian)
    amdgcn     - AMD GCN GPUs
    arm        - ARM
    arm64      - ARM64 (little endian)
    arm64_32   - ARM64 (little endian ILP32)
    armeb      - ARM (big endian)
    avr        - Atmel AVR Microcontroller
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
    hexagon    - Hexagon
    lanai      - Lanai
    mips       - MIPS (32-bit big endian)
    mips64     - MIPS (64-bit big endian)
    mips64el   - MIPS (64-bit little endian)
    mipsel     - MIPS (32-bit little endian)
    msp430     - MSP430 [experimental]
    nvptx      - NVIDIA PTX 32-bit
    nvptx64    - NVIDIA PTX 64-bit
    ppc32      - PowerPC 32
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    r600       - AMD GPUs HD2XXX-HD6XXX
    riscv32    - 32-bit RISC-V
    riscv64    - 64-bit RISC-V
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    wasm32     - WebAssembly 32-bity-xxx-yy'
    wasm64     - WebAssembly 64-bit
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
    xcore      - XCore

@anp
Copy link
Author

anp commented Feb 3, 2021

Right, surprising to have such a recent clang version without wasm, but makes sense. The xcode CLI tools also didn't seem to come with a standalone llc binary, which is a bit more confusing.

I'll try using the prebuilt clang's y'all have in releases and see if I can make progress that way.

@jedisct1
Copy link
Member

jedisct1 commented Feb 3, 2021

You need to install llvm from Homebrew. Xcode's clang doesn't have support for WebAssembly.

@anp
Copy link
Author

anp commented Apr 4, 2021

Indeed, thanks!

@anp anp closed this as completed Apr 4, 2021
kildom pushed a commit to kildom/clang-wasi-port that referenced this issue Jul 14, 2021
aslushnikov added a commit to aslushnikov/playwright that referenced this issue Dec 15, 2021
Firefox requires a bunch of build tools (aka "toolchains") to be built.
Until recently, default MacOS clang (that comes with Xcode) was
sufficient to compile firefox.

However, Firefox 95 started to use WebAssembly. This yielded the following issues specific to MacOS (somehow builds complete successfully on other platforms):

- Default MacOS clang that comes with XCode doesn't support WebAssembly: WebAssembly/wasi-sdk#172 (comment)
- Clang that comes from Homebrew is missing `libclang_rt.builtins-wasm32.a`: https://github.com/jedisct1/libclang_rt.builtins-wasm32.a/blob/79b9b39f9be950110d3a7d6f91d86074349d8302/README.md
- Firefox also requires `wasi sysroot`

Now, depending on which branch firefox checkout comes from
(`mozilla-release` vs `mozilla-beta`), firefox build system **might** or
**might not** be able to download all the required toolchains in the
`$HOME/.mozbuild` folder:
- `mozilla-beta` branch supports toolchain auto-download
- `mozilla-release` **does not** support it yet: https://bugzilla.mozilla.org/show_bug.cgi?id=1744197#c2

The recommended solution is to download toolchains using non-release
firefox branch, and then re-use these toolchains to compile firefox from
release branch.

This patch does exactly this: relies on pre-downloaded toolchains for
release firefox compilation using a combination of `MOZ_AUTOMATION` and
`MOZ_FETCH_DIR` environment variables - these are also used on the
official Firefox CI to compile release builds.

This almost works, but there's a catch: the `MOZ_AUTOMATION` environment
variable auto-adds ("implies") the `--enable-release` configuration
option, which is supposed to yield a better binary, but is also more
picky about the source code: for example, it complains about unused
return values. Browser changes in this patch are addressing these.

References microsoft#10759
aslushnikov added a commit to aslushnikov/playwright that referenced this issue Dec 15, 2021
Firefox requires a bunch of build tools (aka "toolchains") to be built.
Until recently, default MacOS clang (that comes with Xcode) was
sufficient to compile firefox.

However, Firefox 95 started to use WebAssembly. This yielded the following issues specific to MacOS (somehow builds complete successfully on other platforms):

- Default MacOS clang that comes with XCode doesn't support WebAssembly: WebAssembly/wasi-sdk#172 (comment)
- Clang that comes from Homebrew is missing `libclang_rt.builtins-wasm32.a`: https://github.com/jedisct1/libclang_rt.builtins-wasm32.a/blob/79b9b39f9be950110d3a7d6f91d86074349d8302/README.md
- Firefox also requires `wasi sysroot`

Now, depending on which branch firefox checkout comes from
(`mozilla-release` vs `mozilla-beta`), firefox build system **might** or
**might not** be able to download all the required toolchains in the
`$HOME/.mozbuild` folder:
- `mozilla-beta` branch supports toolchain auto-download
- `mozilla-release` **does not** support it yet: https://bugzilla.mozilla.org/show_bug.cgi?id=1744197#c2

The recommended solution is to download toolchains using non-release
firefox branch, and then re-use these toolchains to compile firefox from
release branch.

This patch does exactly this: relies on pre-downloaded toolchains for
release firefox compilation. To re-use pre-downloaded toolchains, we set a
combination of `MOZ_AUTOMATION` and `MOZ_FETCH_DIR` environment
variables - this is the same approach that is used on the official
Firefox CI (see `about:buildconfig` page in the stable firefox 95).

This almost works, but there's a catch: the `MOZ_AUTOMATION` environment
variable auto-adds ("implies") the `--enable-release` configuration
option, which is supposed to yield a better binary, but is also more
picky about the source code: for example, it complains about unused
return values. Browser changes in this patch are addressing these.

References microsoft#10759
aslushnikov added a commit to aslushnikov/playwright that referenced this issue Dec 15, 2021
Firefox requires a bunch of build tools (aka "toolchains") to be built.
Until recently, default MacOS clang (that comes with Xcode) was
sufficient to compile firefox.

However, Firefox 95 started to use WebAssembly. This yielded the following issues specific to MacOS (somehow builds complete successfully on other platforms):

- Default MacOS clang that comes with XCode doesn't support WebAssembly: WebAssembly/wasi-sdk#172 (comment)
- Clang that comes from Homebrew is missing `libclang_rt.builtins-wasm32.a`: https://github.com/jedisct1/libclang_rt.builtins-wasm32.a/blob/79b9b39f9be950110d3a7d6f91d86074349d8302/README.md
- Firefox also requires `wasi sysroot`

Now, depending on which branch firefox checkout comes from
(`mozilla-release` vs `mozilla-beta`), firefox build system **might** or
**might not** be able to download all the required toolchains in the
`$HOME/.mozbuild` folder:
- `mozilla-beta` branch supports toolchain auto-download
- `mozilla-release` **does not** support it yet: https://bugzilla.mozilla.org/show_bug.cgi?id=1744197#c2

The recommended solution is to download toolchains using non-release
firefox branch, and then re-use these toolchains to compile firefox from
release branch.

This patch does exactly this: relies on pre-downloaded toolchains for
release firefox compilation. To re-use pre-downloaded toolchains, we set a
combination of `MOZ_AUTOMATION` and `MOZ_FETCH_DIR` environment
variables - this is the same approach that is used on the official
Firefox CI (see `about:buildconfig` page in the stable firefox 95).

This almost works, but there's a catch: the `MOZ_AUTOMATION` environment
variable auto-adds ("implies") the `--enable-release` configuration
option: https://github.com/mozilla/gecko-dev/blob/9e1cd985485c0e01c5faa9b5072a405b344ebde7/moz.configure#L162

The `--enable-release` is supposed to yield a better binary, but is also more
picky about the source code: for example, it complains about unused
return values. Browser changes in this patch are addressing these.

References microsoft#10759
aslushnikov added a commit to aslushnikov/playwright that referenced this issue Dec 15, 2021
Firefox requires a bunch of build tools (aka "toolchains") to be built.
Until recently, default MacOS clang (that comes with Xcode) was
sufficient to compile firefox.

However, Firefox 95 started to use WebAssembly. This yielded the following issues specific to MacOS (somehow builds complete successfully on other platforms):

- Default MacOS clang that comes with XCode doesn't support WebAssembly: WebAssembly/wasi-sdk#172 (comment)
- Clang that comes from Homebrew is missing `libclang_rt.builtins-wasm32.a`: https://github.com/jedisct1/libclang_rt.builtins-wasm32.a/blob/79b9b39f9be950110d3a7d6f91d86074349d8302/README.md
- Firefox also requires `wasi sysroot`

Now, depending on which branch firefox checkout comes from
(`mozilla-release` vs `mozilla-beta`), firefox build system **might** or
**might not** be able to download all the required toolchains in the
`$HOME/.mozbuild` folder:
- `mozilla-beta` branch supports toolchain auto-download
- `mozilla-release` **does not** support it yet: https://bugzilla.mozilla.org/show_bug.cgi?id=1744197#c2

The recommended solution is to download toolchains using non-release
firefox branch, and then re-use these toolchains to compile firefox from
release branch.

This patch does exactly this: relies on pre-downloaded toolchains for
release firefox compilation. To re-use pre-downloaded toolchains, we set a
combination of `MOZ_AUTOMATION` and `MOZ_FETCH_DIR` environment
variables - this is the same approach that is used on the official
Firefox CI (see `about:buildconfig` page in the stable firefox 95).

This almost works, but there's a catch: the `MOZ_AUTOMATION` environment
variable auto-adds ("implies") the `--enable-release` configuration
option: https://github.com/mozilla/gecko-dev/blob/9e1cd985485c0e01c5faa9b5072a405b344ebde7/moz.configure#L162

The `--enable-release` is supposed to yield a better binary, and we want
builds to be the same across platforms, so this patch adds this option
**unconditionally on all platforms**.

The `--enable-release` is also more picky about the source code: for
example, it complains about unused return values. Browser changes in
this patch are addressing these.

References microsoft#10759
@IgorKhomenko
Copy link

brew install llvm
echo 'export PATH="/opt/homebrew/opt/llvm/bin:$PATH"' >> ~/.zshrc

works for me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants