choice of TARGET_CC or HOST_CC does not seem consistent

[saurik]

Hello! So I do a lot of cross compiling. In one case, on Linux x86_64, I need to cross compile for Linux x86_64 (no typo), as I need to 1) use a very specific compiler and 2) have a sysroot I need to use as it has a very specific (and old) version of glibc (from CentOS 6). Notably, I am striving for reproducible builds, something I was having no problems with until I started linking against a rust library :(. (In specific, the library I'm using depends on ring, which has some native code.)

So, the way I'd expect HOST_CC and TARGET_CC to work is that there are essentially two levels of build: there's stuff being built to be used by the build, and then there's stuff being built to be deployed after the build; everything in the former category should use HOST_CC, and everything in the latter category should use TARGET_CC. This is, for example, how other build systems--such as autotools--handles choosing compilers (at worst they print an awkward warning).

Now, with Cargo, when I compile on a macOS machine, I use TARGET_CC to specify my very specific Linux x86_64 compiler, and this works "as expected": any code that is supposed to be run on macOS uses HOST_CC and any code that is supposed to be deployed is built using TARGET_CC. However, when I compile on a Linux x86_64 system, this doesn't happen: instead, as far as I can tell, everything uses HOST_CC always, even stuff that is going to be deployed :(.

I figure the logic here is "I'm on a Linux x86_64 system, and I just need any compiler, right? so why can't I just use the HOST_CC here?", but again: the issue is that I might have some very "good" reason for having different compilers that goes beyond "does it run?" and moves into the world of "does it provide bit-for-bit identical results with some other machine that is also building this code because I want to reproduce that build" or "I have weird glibc requirements".

(This might be related in some way to #3349, btw; but, while I am not entirely sure what build-script-build is, it sounds like that bug is more from long enough ago that TARGET_CC might simply not have existed, and so the issue was more that there was no way to specify this at all, as opposed to that it was being selected in weird ways? FWIW, I don't feel a need for anything lower-level than TARGET_CC: I just want TARGET_CC to always be used as the target cc ;P.)

(FWIW, in this case, I feel like I'm going to be able to come up with a messy workaround for this wherein I detect cases where I think the wrong variable will be used and pass HOST_CC instead, but that isn't viable in the general case: as an example, maybe I want to compile to target some newer platform version than the one I'm currently running on using some version variant switch, in which case the TARGET_CC might generate object files that are invalid on my host system.)

Maybe put most simply: my assertion is that the choice of HOST_CC or TARGET_CC should be based on what I'm intending to do with the thing being compiled, as opposed to what amounts to an unpredictable decision based upon whether the host and target happen to share a triple (which is by no means a guarantee of full compatibility, whether practically or conceptually); the host and target are semantically different from each other in ways unrelated to their platform.

(Note: it is totally possible that this is some issue specific to ring, but I couldn't find any mention of TARGET_CC in their code so I got the impression that they were just asking Cargo to build stuff Cargo was taking care of it; but I also don't know how Cargo packages are formatted and so haven't dug into ring to determine exactly how this is all specified either. So, if this isn't even an issue in Cargo and this is actually an issue with ring, I'm super sorry for wasting your time.)

[ehuss]

Cargo doesn't execute C compilers. It looks like ring uses the cc package to handle building C code.

[alexcrichton]

This is sort of arguably a Cargo bug though because build scripts have no way of distinguishing cargo build and cargo build --target $host. The problem is likely on this line which checks for host == target to select which compiler to use.

[alexcrichton]

Or rather not so much as a Cargo bug but rather a Cargo feature request.

[saurik]

In case it is useful to anyone else, my latest workaround for this issue is to run rustc --version --verbose | sed -e '/^host: /!d;s///' (a feature that I am not sure existed a year ago, though I'm not sure I would have thought to look at the time anyway) and compare it with my --target, so I know which environment variables--either TARGET_* or HOST_*--to set (which is definitely much cleaner than the haphazard heuristics I used to have, but I will note still is not a comprehensive solution as it assumes that the target compiler and flags are always going to be able to generate binaries that can run on my current machine, which certainly isn't guaranteed for a number of reasons, including-but-not-limited-to those mentioned in #6375, which is a problem with a similar concept that occurs at a very different location in the standard Rust build stack).