cargo doesn't set cross-compiler GCC variables

[GlenDC]

For one of my projects in production I am targeting arm_linux_androideabi and i686_linux_android. Thanks to the .android/config file I can specify the linkers as follows:

[target.arm-linux-androideabi]
linker = "<TOOLCHAINS>/A14-arm-4.8/bin/arm-linux-androideabi-gcc"

[target.i686-linux-android]
linker = "<TOOLCHAINS>/A14-x86-4.8/bin/i686-linux-android-gcc"

This makes my project compile with all dependencies, except for openssl_rust. While building the openssl_rust it also compiles a small C layer using GCC. The problem is that this goes outsides the RUST environment and thus we lose this cross-compiler information set in the Cargo Config file.

According to @sfackler there are environment variables that can be set such as CC_arm_linux_androideabi and CC_i686_linux_android (for the android targets I need). This would make GCC recognize the correct cross compiler.

So I was wondering, as we're already giving cargo our cross-compiler information. Could Cargo perhaps set these variables, so that dependencies that have C code to build with GCC, work without me having to specifically set some extra and different environment variables for each of my different cargo builds. (one per android target)

[alexcrichton]

Thanks for the report! This is pretty similar to rust-lang/cc-rs#82 which is somewhat the opposite of this, having gcc-rs read off configuration rather than Cargo specifying it. I somewhat prefer that route as unfortunately linker isn't enough to tell gcc-rs how to operate. It needs a C/C++ compiler as well as an ar tool, and the linker passed to rustc isn't necessarily guaranteed to actually be a C compiler.

cc @brson and @japaric, do you have thoughts on what the best route to take here is? It's unfortunate that cross compilation does require configuration in more than one location, but maybe I should just bite the bullet and tackle rust-lang/cc-rs#82, allowing reading .cargo/config from the gcc-rs crate?

[brson]

@alexcrichton Doing it in gcc-rs sounds like a good conservative first solution to me. I don't really have a problem with uber-crates encoding lots of difficult logic themselves. In Rust when you want to compile C you use the gcc crate, so it's not too outrageous to centralize the logic there and not impose new maintenance burden on cargo proper.

[japaric]

I somewhat prefer that route as unfortunately linker isn't enough to tell gcc-rs how to operate. It needs a C/C++ compiler as well as an ar tool, and the linker passed to rustc isn't necessarily guaranteed to actually be a C compiler.

Doesn't this apply to both cases? gcc-rs would also have to derive ar, cc and cxx from the .cargo/config linker somehow.

maybe I should just bite the bullet and tackle rust-lang/cc-rs#82, allowing reading .cargo/config from the gcc-rs crate?

In theory, reading .cargo/config is not enough. linker and ar can also be set in the target specification. gcc-rs would have to read that as well to get the "real" value of linker/ar, but AFAIK there's no way to access the specification of a built-in target (for custom targets you can parse the associated .json file). However, in practice, only reading .cargo/config may be enough.

That being said, I would prefer a first solution in gcc-rs rather than in Cargo because it feels more direct; using Cargo would involve messing around with env variables to pass the information to gcc-rs/build.rs and those would have to be stabilized (i.e. they would become de facto stable).

[alexcrichton]

@japaric yeah linker and ar aren't enough for gcc-rs to operate, but I was thinking that config would at least be centralized in .cargo/config, which gcc-rs would read, and there'd just be stuff in there that Cargo ignores.

[alexcrichton]

In any case, though, I'm gonna close this in favor of rust-lang/cc-rs#82, but thanks for the report @GlenDC!