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

Front End build error: LLVM TargetMachine for triple: wasm32-unknown-unknown #576

Closed
trouperk opened this issue Oct 22, 2019 · 5 comments
Closed
Labels
bug Something isn't working

Comments

@trouperk
Copy link

First off, thanks for a the work in putting together this comprehensive repo! It is invaluable for a newbie, like me, in making progress!

I am running into an error that I can't seem to find an answer for.

Error Message when running sudo make all:

error: Could not create LLVM TargetMachine for triple: wasm32-unknown-unknown: No available targets are compatible with triple "wasm32-unknown-unknown"

thread 'main' panicked at 'Failed to grab the target configuration from rustc!', /home/trouperk/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-web-0.6.26/src/cargo_shim/mod.rs:178:13
note: Run with RUST_BACKTRACE=1 environment variable to display a backtrace.
Makefile:53: recipe for target 'build-frontend' failed
make: *** [build-frontend] Error 101

End Error Message

What has me confused on this issue is the following:

  • I successfully ran sudo make all initially and the build succeeded. Unfortunately, I hadn't noticed that I already had a local psql server running on port 5432 so I hit an error running the postgre container.
  • So I stopped the local version I had and attempted to re-make (in retrospect, I realize this was probably unnecessary after stopping my local process). It was, at that point that I hit this error message.
  • I have tried removing the entire folder and starting the process over with no success (using both the main repo directions and those found in issue/ticket clarify build environment #480).
  • I also did a force reinstall of cargo-web.
  • I know that the LLVM target issue for wasm32-unknown-unknown appears quite a bit as an error message (according to Google), but I've compiled to it previously, I double checked that I can still compile an existing project targeting wasm32-unknown-unknown, and, as mentioned above, it worked initially.

Machine and Version Info:

  • Ubuntu 18.04
  • rustup 1.20.2
  • rustc 1.39.0-nightly
  • cargo 1.39.0-nightly
  • rustc --print target-list includes an entry for: wasm32-unknown-unknown
  • results of rustup show:

Beginning
Default host: x86_64-unknown-linux-gnu
rustup home: /home/trouperk/.rustup

installed toolchains

stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)

installed targets for active toolchain

asmjs-unknown-emscripten
wasm32-unknown-emscripten
wasm32-unknown-unknown
x86_64-unknown-linux-gnu

active toolchain

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.39.0-nightly (6ef275e6c 2019-09-24)

End

Please let me know if there is any additional information I should provide. And thanks in advance for any ideas/suggestions!

@issue-label-bot
Copy link

Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.81. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

@issue-label-bot issue-label-bot bot added the bug Something isn't working label Oct 22, 2019
@saschagrunert
Copy link
Owner

Hey @trouperk thanks for the detailed report. 🙏 Do you see this kind of issue with the stable toolchain too?

@trouperk
Copy link
Author

Thanks for the response @saschagrunert! I did some further troubleshooting yesterday to try to narrow down the issue.

  • I updated rustc-nightly to 1.40
  • I switched over to the stable toolchain
  • Reinstalled/updated cargo-web and the wasm32-unknown-unknown target
  • I also also explored alternate modes of execution using cargo build w/ specified target rather than cargo web
  • And I tried building the frontend directly from the frontend folder with both a simple Makefile and direct command line
  • None of the above changed the result

I decided to test cargo-web & my wasm32 target.

  • I made a simple 'add_one' lib (cargo new --lib add_one) and built versions with both cargo build --release --target wasm32-unknown-unknown and with cargo web build --release. Both versions finished successfully and I was able to find the .wasm file in target release.
  • I also re-build several existing webpack and wasm builds (wasm_game_of_life for example) successfully
  • For the last test I completed yesterday, I made a simple Yew counter. It was an older version of Yew, but it built successfully with both cargo and cargo-web.

With all that testing, I think that my wasm32-unknown-unknown target is good and I think that cargo-web is working. With having also tried sudo rm -rf webapp.rs and recloning without a change in result, I have two ideas where to look from here:

  1. There is an artifact somewhere on my machine that persists outside the webapp.rs folder
  2. There is a line of code somewhere in the frontend that is causing the system to not 'see' the target

I will keep checking it out on my side... I lean towards #1 if no one else is having an issue.

@trouperk
Copy link
Author

I have an update on this and a resolution. Short version... operator error on my side!

The issue had to do with permissions for docker compared to make and rust. The first time through the build I entered commands almost verbatim through the build process, but had to use sudo for executing make run-app. After correcting the initial issue with the my existing psql server, I used sudo make all rather than regular make all. On my system, docker requires sudo (which is why I used it with make run-app which calls the container command), but I didn't have all the Rust toolchain set up for sudo which is why the wasm32 build failed when run as sudo even though the target was visible for regular rustc.

Rookie mistake! Didn't even cross my mind at the time. I'm closing this issue. Thanks again for putting this repo together!

@saschagrunert
Copy link
Owner

Alright thanks for the feedback. If you see further improvements feel free to open up an issue or PR. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants