Open chenrui333 opened 3 weeks ago
@chenrui333 at a guess, ensure that homebrew's llvm contains libclang_rt.osx.a
?
ninja: error: '../../../../../../../opt/homebrew/opt/llvm/lib/clang/20/lib/darwin/libclang_rt.osx.a', needed by 'obj/v8/libv8_libbase.a', missing and no known rule to make it
yeah, we have it
$ fd libclang_rt.osx.a /opt/homebrew/Cellar/
/opt/homebrew/Cellar/llvm/18.1.8/lib/clang/18/lib/darwin/libclang_rt.osx.a
but that is under 18
Sounds like you need to ensure your llvm 20 installation has the needed components or switch to using your llvm 18 installation?
getting a similar error (in opensuse)
ninja: error: '../../../../../../../../usr/lib/clang/20/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a', needed by 'obj/v8/libv8_libbase.a', missing and no known rule to make it
thread 'main' panicked at build.rs:965:3:
assertion failed: ninja(&gn_out_dir, maybe_env).arg(target).status().unwrap().success()
I googled and found this, perhaps your llvm distributions need to be updated: https://stackoverflow.com/questions/76936217/how-to-build-libclang-rt-builtins-a
llvm 20 is not the latest release
any how that both llvm18 and 20 can be supported? if not, that would be the one supporting llvm18?
I don't think the version matters, i think the issue is that you have built llvm without compiler-rt enabled. If you want the compiler-rt requirement removed you will need to implement patches in the upstream chromium repo which we could then pull into rusty_v8.
I looked into this, I believe the issue is that the build assumes you're using clang version 20, even when you set a custom clang base path. So then it looks for that static library under the incorrect path.
We should probably be detecting the clang version and passing it along in build.rs
.
For now, to fix the build you can try adding the env var
GN_ARGS='clang_version=18 use_lld=false'
(assuming the version in homebrew is 18, which it currently is).
The use_lld=false
arg may not be necessary, but I found that locally I needed it to get the build working.
While packaging for Arch, we encountered this as well. Unfortunately the above workaround didn't work for us because our compiler-rt (which was built separately as a package) installs the file as /usr/lib/clang/18/lib/linux/libclang_rt.builtins-x86_64.a
, which here it looks for /usr/lib/clang/18/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a
.
Any idea how can I get around this?
The configuration is here: https://source.chromium.org/chromium/chromium/src/+/main:build/config/clang/BUILD.gn
Seems like you can probably follow along with chromium packaging: https://gitlab.archlinux.org/archlinux/packaging/packages/chromium/-/blob/main/compiler-rt-adjust-paths.patch?ref_type=heads
I see, thanks for the hint. Hacking this into the Rust building process is much more frustrating though...
👋 trying to build the latest deno 1.46.0 release, but run into some build issue with rusty_v8 0.104.0. The error log is as below:
error build log
``` --- stderr ninja: error: '../../../../../../../opt/homebrew/opt/llvm/lib/clang/20/lib/darwin/libclang_rt.osx.a', needed by 'obj/v8/libv8_libbase.a', missing and no known rule to make it thread 'main' panicked at /private/tmp/deno-20240822-12060-mwfxfo/rusty_v8/build.rs:969:3: assertion failed: ninja(&gn_out_dir, maybe_env).arg(target).status().unwrap().success() note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: failed to compile `deno v1.46.0 (/private/tmp/deno-20240822-12060-mwfxfo/deno/cli)`, intermediate artifacts can be found at `/private/tmp/deno-20240822-12060-mwfxfo/deno/target`. To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path. ```full build log, https://github.com/Homebrew/homebrew-core/actions/runs/10507035952/job/29108048297?pr=181980 relates to Homebrew/homebrew-core#181980