Summary: | dev-lang/rust [wasm]: error: linker `rust-lld` not found | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | deso |
Component: | Current packages | Assignee: | Georgy Yakovlev <gyakovlev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jstein, rust |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://github.com/rust-lang/rust/issues/70589 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
wasm test project
equery uses rust unrelated patch I have applied for the rust ebuild builds logs |
Description
deso
2020-03-29 19:51:21 UTC
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! |