Created attachment 627018 [details] wasm test project I am seeing the following error when compiling a webassembly project using dev-lang/rust-1.42.0 (emerged with 'wasm' USE flag): > $ cargo build --release --target=wasm32-unknown-unknown > error: linker `rust-lld` not found > | > = note: No such file or directory (os error 2) > > error: aborting due to previous error I know for sure that this worked in the past with a different version of Rust, but I don't recall which. Only related bug report I've found: https://github.com/rust-lang/rustup/issues/1843 Managed to get it working using rust-lld from a nightly rust-bin installation I happen to have lying around, like so: RUSTFLAGS="-C linker=/opt/rust-bin-20200218/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld" cargo build --target=wasm32-unknown-unknown Also seemingly working, after manual installation of sys-devel/lld: RUSTFLAGS="-C linker=/usr/bin/lld" cargo build --release --target=wasm32-unknown-unknown
Created attachment 627020 [details] equery uses rust
question how did you end up needing to manually install lld? we have a dependency on it, so it should have been pulled with system-llvm. wasm? ( =sys-devel/lld-9* ) and we pass if use wasm; then [target.wasm32-unknown-unknown] linker = "$(usex system-llvm lld rust-lld)" so you should already have lld linker set for wasm32-unknown-unknown target to me it looks like you've build rust without wasm enabled, because it's still looking for rust-lld and not lld, which we set explicitly. you have 2 symptoms of wasm being disabled: missing deps, missing linker setting. did you do any manual ebuild installations (with ebuild and not emerge?) the only other reason for failure I see is that we don't set llvm-config path in wasm target. I'll investigate that. can you rebuild, upload build log and try again?
(In reply to Georgy Yakovlev from comment #2) > question > how did you end up needing to manually install lld? > > we have a dependency on it, so it should have been pulled with system-llvm. > > wasm? ( =sys-devel/lld-9* ) Well, I looked at the ebuild before and I concluded that I don't understand the syntax enough to determine whether it is doing the right thing. LLVM_DEPEND=" || ( sys-devel/llvm:9[${LLVM_TARGET_USEDEPS// /,}] wasm? ( =sys-devel/lld-9* ) ) <sys-devel/llvm-10:= " Why is there what appears to be an OR? And what does the additional conditional 'wasm?' mean *in this context*? If there is llvm:9, does it still matter whether 'wasm` is set? Does not seem to be the case as lld is definitely not a dependency here. If I do an emerge depclean the sys-devel/lld package is slated for removal, despite 'wasm' USE flag being set and present for dev-lang/rust. > did you do any manual ebuild installations (with ebuild and not emerge?) No. Didn't even know that was possible. I do have a slightly modified ebuild, but the modifications don't affect any of that. > the only other reason for failure I see is that we don't set llvm-config > path in wasm target. I'll investigate that. > > can you rebuild, upload build log and try again? Will do.
Created attachment 627328 [details, diff] unrelated patch I have applied for the rust ebuild
Created attachment 627474 [details] builds logs
It seems that after a re-emerge things are working without problems. I did have lld installed during the emerge, though, not sure if that could make a difference.
(In reply to deso from comment #6) > It seems that after a re-emerge things are working without problems. I did > have lld installed during the emerge, though, not sure if that could make a > difference. Sorry no, not true. Nothing has changed. I tested with the non-wasm target... Still getting the same error with --target=wasm32-unknown-unknown.
actually, you are absolutely right, dependency is incorrectly written. it's here from times when rust ebuild supported multiple llvm versions and not locked just to a single one. it should totally move outside of || block. thanks for catching it. doing a build with wasm currently to test the project, thanks for providing testcase.
rustc -Z unstable-options --target=wasm32-unknown-unknown --print target-spec-json { "arch": "wasm32", "data-layout": "e-m:e-p:32:32-i64:64-n32:64-S128", "default-hidden-visibility": true, "dll-prefix": "", "dll-suffix": ".wasm", "dynamic-linking": true, "emit-debug-gdb-scripts": false, "env": "", "exe-suffix": ".wasm", "executables": true, "has-elf-tls": true, "is-builtin": true, "limit-rdylib-exports": false, "linker": "rust-lld", "linker-flavor": "wasm-ld", "lld-flavor": "wasm", "llvm-target": "wasm32-unknown-unknown", "max-atomic-width": 64, "only-cdylib": true, "os": "unknown", "panic-strategy": "abort", "pre-link-args": { "gcc": [ "-Wl,--no-threads", "-Wl,-z", "-Wl,stack-size=1048576", "-Wl,--stack-first", "-Wl,--allow-undefined", "-Wl,--fatal-warnings", "-Wl,--no-demangle", "-Wl,--export-dynamic", "--target=wasm32-unknown-unknown", "-nostdlib", "-Wl,--no-entry" ], "wasm-ld": [ "--no-threads", "-z", "stack-size=1048576", "--stack-first", "--allow-undefined", "--fatal-warnings", "--no-demangle", "--export-dynamic", "--no-entry" ] }, "relocation-model": "static", "simd-types-indirect": false, "singlethread": true, "target-c-int-width": "32", "target-endian": "little", "target-pointer-width": "32", "tls-model": "local-exec", "vendor": "unknown" } for some reason linker is still set to rust-lld I'll dig into that. at least you have a workaround for now with RUSTFLAGS
another tip, you can set export CARGO_TARGET_WASM32_UNKNOWN_UNKNOWN_LINKER=wasm-ld and it will use linker just for this target, not for all of them
Seems the Rust team doesn't see an issue on their side. What's the stance here?
Very convenient workaround exists, I could just print a postinst message with instructions. Or maybe we can sed target specification at configure time if wasm and system llvm is enabled to force specific linker. Lld path seems to be stable.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a4c22a8c26d3eba78f2bb5835645c34dcb9def55 commit a4c22a8c26d3eba78f2bb5835645c34dcb9def55 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-06-18 22:43:14 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-06-18 23:50:11 +0000 dev-lang/rust: un-hardcode wasm linker if system-llvm is used Bug: https://bugs.gentoo.org/715348 Package-Manager: Portage-2.3.101, Repoman-2.3.22 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/rust-1.44.1.ebuild | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
please test and let me know if it works
(In reply to Georgy Yakovlev from comment #14) > please test and let me know if it works The fix seems to work for me. Thanks!
thanks for testing! not going to backport it, because easy workaround exists and I don't want to force rebuilds for users. closing.
Unfortunately, in rust-1.53.0, wasm32_base.rs was renamed to wasm_base.rs. So the ebuild fails while configuring, Please fix.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8d278099b7e562d0e9fe22ac41576b4ddf919884 commit 8d278099b7e562d0e9fe22ac41576b4ddf919884 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2021-06-19 11:15:11 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2021-06-19 11:15:44 +0000 dev-lang/rust: unbreak wasm in 1.53 Bug: https://bugs.gentoo.org/715348 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/rust-1.53.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
thanks for reporting!
