Can't Link Custom Static Libraries #1766
-
|
So the project I am trying to cross-compile uses a client socket to communicate with another program on my Raspberry Pi. The Rust socket functions didn't work as well on the Pi as they did on my desktop, so I'm going to use a C++ socket instead. I compiled that into a .a static library, saved it in ./lib, tested with cargo run, it worked perfectly. When I went to cross-compile it for the Pi, I recompiled the static library for aarch64 successfully but when I tried cross build, I got this: The static library was recompiled for aarch64, it's in the same lib folder, the title should be correct (libaibusclient.a), why doesn't cross seem to be seeing it? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 10 replies
-
|
The issue is likely that The most reliable fix is using a // build.rs
fn main() {
let dir = std::env::var("CARGO_MANIFEST_DIR").unwrap();
println!("cargo:rustc-link-search=native={}/lib", dir);
println!("cargo:rustc-link-lib=static=your_lib_name");
// You likely need to link the C++ runtime explicitly as well
println!("cargo:rustc-link-lib=stdc++");
}One gotcha to watch out for: ensure your static library follows the |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately that yielded the same error. Tried moving the c++ link towards the end, same issue. The naming convention is correct. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, that's surprising - I tested the A couple things to check: First, make sure you ran Second, can you add some debug output to your build.rs to verify what paths are actually being used? Something like: fn main() {
let dir = std::env::var("CARGO_MANIFEST_DIR").unwrap();
eprintln!("=== MANIFEST_DIR: {} ===", dir);
let lib_path = format!("{}/lib", dir);
eprintln!("=== LIB EXISTS: {} ===", std::path::Path::new(&format!("{}/libaibusclient.a", lib_path)).exists());
println!("cargo:rustc-link-search=native={}", lib_path);
println!("cargo:rustc-link-lib=static=aibusclient");
println!("cargo:rustc-link-lib=dylib=stdc++");
}Run Also worth checking - do you have |
Beta Was this translation helpful? Give feedback.
-
|
It resolved to /project but can't find the library... hmm.... Nothing like that in Cargo.toml, here is my Cross.toml: The .a file is a symbolic link so I don't have to keep copying it, could that have something to do with it? |
Beta Was this translation helpful? Give feedback.
-
|
That's the issue - the symlink. When The fix: replace the symlink with the actual file. Either copy it directly: cp -L lib/libaibusclient.a lib/libaibusclient.aOr if you want to keep building the lib separately and having it auto-update, add a pre-build step to your workflow that dereferences the symlink before running # Dereference all symlinks in lib/
for f in lib/*.a; do
if [ -L "$f" ]; then
cp --remove-destination "$(readlink -f "$f")" "$f"
fi
done
cross build --target=aarch64-unknown-linux-gnuI reproduced this exact error in a sandbox - symlink works fine with |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! Looks like my C++ library is out of date, I'm now getting an "undefined reference to `std::__throw_bad_array_new_length()." Hopefully that is an easier fix. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that's a libstdc++ version mismatch. Your host compiles the C++ lib with GCC 13.3 (Ubuntu 24.04), but the cross container Easiest fix: build the C++ lib inside the cross container using a [target.aarch64-unknown-linux-gnu]
pre-build = [
"apt-get update && apt-get install -y g++",
"g++ -c /project/lib/client.cpp -o /project/lib/client.o",
"ar rcs /project/lib/libaibusclient.a /project/lib/client.o"
]This compiles the Alternative: use a newer cross image that has a modern GCC. You can set a custom image in [target.aarch64-unknown-linux-gnu]
image = "ghcr.io/cross-rs/aarch64-unknown-linux-gnu:main"The |
Beta Was this translation helpful? Give feedback.
-
|
Thanks!! I will have to de-reference a lot... 
|
Beta Was this translation helpful? Give feedback.
-
|
I tried this during my lunch break and had one more quick question- g++ can't find the /project directory, I ran an |
Beta Was this translation helpful? Give feedback.
That's the issue - the symlink. When
crossmounts your project into Docker at/project, it copies the symlink itself but the target it points to doesn't exist inside the container. So the linker sees a broken symlink and can't find the.afile.The fix: replace the symlink with the actual file. Either copy it directly:
Or if you want to keep building the lib separately and having it auto-update, add a pre-build step to your workflow that dereferences the symlink before running
cross: