Front End build error: LLVM TargetMachine for triple: wasm32-unknown-unknown
trouperk opened this issue · comments
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 #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 is automatically applying the label bug to this issue, with a confidence of 0.81. Please mark this comment with
Links: app homepage, dashboard and code for this bot.
Hey @trouperk thanks for the detailed report.
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:
- There is an artifact somewhere on my machine that persists outside the webapp.rs folder
- 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.
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!
Alright thanks for the feedback. If you see further improvements feel free to open up an issue or PR. :)