Hello, I'm working on a project that's generating some C binaries, but those binaries must link in a Rust static library I'm writing. The binaries need to be statically linked (so I'm using musl libc) and cross compiled for several architectures (currently x86_64, mips, and arm). I installed the necessary cross-compiled targets with rustup (x86_64-unknown-linux-musl, mips-unknown-linux-musl, and arm-unknown-linux-musleabi), built my crate as a static lib for those targets, then linked the Rust static libs into my C binaries.
I started running into some strange crashes when running the binaries (all of them happening while invoking libc calls), when I realized something potentially problematic: the toolchains used to generate these Rust cross-compiled targets are almost certainly not the same as the toolchains I'm using to compile/link my C code. In particular, the static libs that I generate from my Rust crate contain all the libc symbols from
liblibc-<HASH>.rlib from the Rust toolchain. I don't exactly know how the linking process is going to deal with those symbols being defined both by
libc.a and this Rust static lib, but it doesn't give me a good feeling...
To try and resolve my issues, I thought that I might need to compile rustc using the same toolchains (same gcc + musl libc versions) that I plan on using for my C code. Does this seem like the right course of action? I figured that poking around the various scripts in
src/ci/docker from the Rust language repo might lead me in the right direction, and hopefully I can adapt them for the versions of musl/gcc that I'm using. Is that the right place to start looking? Are those scripts the same ones that generate the stable Rust releases?
I forgot to mention it, but I'm trying to stick with stable Rust versions, and the host architecture that I'm working on is x86_64-unknown-linux-gnu.
Thanks so much for any help!