You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, this is more of a question than a bug report (but a bug report will be provided nevertheless).
Context
While attempting to use the rustls crate with the aws-lc-rs backend, I ran into an interesting linker error, that only exhibited itself during any binary-ish (rust_binary, rust_test, etc) target build.
It looks like this, cleaned up:
error: linking with `<toolchains_llvm sysroot'd cc_wrapper>` failed: exit status: 1
|
= note: lld: error: undefined symbol: aws_lc_0_24_0_CRYPTO_library_init
>>> referenced by aws_lc_rs.cfa660e1dffe16e2-cgu.6
>>> <...>/bazel-out/k8-fastbuild/bin/external/crates_io__aws-lc-rs-1.12.0/libaws_lc_rs-966159758.rlib(aws_lc_rs-966159758.aws_lc_rs.cfa660e1dffe16e2-cgu.6.rcgu.o):(aws_lc_rs::init::_$u7b$$u7b$closure$u7d$$u7d$::h59c78008fe3385f8)
collect2: error: ld returned 1 exit status
<... and many, many more such errors>
Bug description
After some hours beating around the wrong bushes, I eventually realized something interesting (and the cause of the link issues); aws-lc-sys uses a versioned prefix for their exported symbols in the form aws_lc_%version_%symbol, and consequently, aws-lc-rs wants to link against (in my case) aws_lc_0_24_0_%symbol prefixed symbols.
However, the .rlib of the aws-lc-sys crate, contained symbols like aws_lc_0_0_0_%symbol -- and if you've ever watched the output of build --subcommands on rust targets, you know where this is going. rules_rust will typically set the CARGO_PKG_VERSION of non crate builds to 0.0.0; however differently to upstream cargo, it also sets the compile of the build script itself to 0.0.0, rather than inheriting the "parent" crate's CARGO_PKG_VERSION. This, combined with aws-lc-sys's use of std::env!, uses the compile time value, rather than what is set at the build script runtime.
And here we come to the question:
Is this a rules_rust issue?
I think aws-lc-sys is doing the wrong thing here, and should instead be reading this value at runtime
But the official rust build tool (cargo) handles this case fine, and not supporting this behavior can and will lead to other subtle issues down the road
I'm asking here first, because technically this issue only exists under rules_rust's cargo machinery. Otherwise (and maybe regardless of what happens here) I'll open an issue with them, too because it seems weird to prebake the prefix into the builder, rather than reading it, from the buildenv during builder runtime.
// ./src/main.rsfnmain(){/* * Just need to use _something_ from the crate to ensure rustc does * actually bother to link */
aws_lc_rs::init();println!("Hello, world!")}
patch/fix-symbol-versioning.patch
diff --git a/builder/main.rs b/builder/main.rs
index 3619a421d1..4bebe1ac57 100644
--- a/builder/main.rs+++ b/builder/main.rs@@ -210,7 +210,9 @@ impl OutputLib {
const VERSION: &str = env!("CARGO_PKG_VERSION");
fn prefix_string() -> String {
- format!("aws_lc_{}", VERSION.to_string().replace('.', "_"))+ let version = std::env::var("CARGO_PKG_VERSION")+ .expect("CARGO_PKG_VERSION to be set when running the build script");+ format!("aws_lc_{}", version.replace('.', "_"))
}
#[cfg(feature = "bindgen")]
So, this is more of a question than a bug report (but a bug report will be provided nevertheless).
Context
While attempting to use the
rustls
crate with theaws-lc-rs
backend, I ran into an interesting linker error, that only exhibited itself during any binary-ish (rust_binary
,rust_test
, etc) target build.It looks like this, cleaned up:
Bug description
After some hours beating around the wrong bushes, I eventually realized something interesting (and the cause of the link issues);
aws-lc-sys
uses a versioned prefix for their exported symbols in the formaws_lc_%version_%symbol
, and consequently, aws-lc-rs wants to link against (in my case)aws_lc_0_24_0_%symbol
prefixed symbols.However, the .rlib of the aws-lc-sys crate, contained symbols like
aws_lc_0_0_0_%symbol
-- and if you've ever watched the output ofbuild --subcommands
on rust targets, you know where this is going. rules_rust will typically set theCARGO_PKG_VERSION
of non crate builds to0.0.0
; however differently to upstream cargo, it also sets the compile of the build script itself to 0.0.0, rather than inheriting the "parent" crate'sCARGO_PKG_VERSION
. This, combined with aws-lc-sys's use of std::env!, uses the compile time value, rather than what is set at the build script runtime.And here we come to the question:
I'm asking here first, because technically this issue only exists under rules_rust's cargo machinery. Otherwise (and maybe regardless of what happens here) I'll open an issue with them, too because it seems weird to prebake the prefix into the builder, rather than reading it, from the buildenv during builder runtime.
MVB
WORKSPACE
BUILD
src/main.rs
patch/fix-symbol-versioning.patch
.bazelversion
.bazelrc
Or see the attached rules_rust_mvb.tar.gz
You can easily trigger this bug on any linux system with
build-essential
(or equivalent) installed via:If you want to investigate the sys .rlib file:
The text was updated successfully, but these errors were encountered: