Cross-compiling fails with gcc-rs

[dm0-]

I am unable to cross-compile via cargo build --target when projects use gcc-rs if the host binutils has libraries in /usr/lib and the cross-binutils libraries are elsewhere. It causes the cross-compiler programs to use the host libraries with bad results. Here is an example failure message:

running: "aarch64-pc-linux-gnu-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-o" ".../target/aarch64-unknown-linux-gnu/debug/build/miniz-sys-5f6a8260c5d6f474/out/miniz.o" "-c" "miniz.c"
cargo:warning=Assembler messages:
cargo:warning=Fatal error: selected target format 'elf64-littleaarch64' unknown
ExitStatus(ExitStatus(256))

The problem is from cargo setting LD_LIBRARY_PATH with /usr/lib (where /usr is the --print=sysroot value). It also adds that path before adding the LD_LIBRARY_PATH from the environment, so it can't be overridden. I thought of specifying --sysroot via RUSTFLAGS to change the LD_LIBRARY_PATH value, but env_args in context.rs forbids this. (See #4423.)

So far, I have only managed to get these builds working by either wrapping rustc in a script that adds --sysroot, or by wrapping the cross-compilers in a script that unsets LD_LIBRARY_PATH. Am I missing a better way to handle this?

[alexcrichton]

Hm Cargo nowadays shouldn't be setting LD_LIBRARY_PATH to system directories, what version are you using?

[dm0-]

I tried 0.20.0 and 0.21.0.

It seems to be creating the system libdir path at https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_rustc/context.rs#L288 and adding it to LD_LIBRARY_PATH at https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_rustc/compilation.rs#L128 .

[alexcrichton]

Oh interesting! You've got rustc installed at /usr?

I didn't even realize we had that block, but yeah we probably shouldn't be setting that in LD_LIBRARY_PATH regardless there (but rather pursuing alternate solutions)

[dm0-]

Yes, this is the default setup on Gentoo. If it avoids setting LD_LIBRARY_PATH altogether here, that should solve my problem. Thanks.

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[stale]

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!