Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to specify configuration for host compilation #5754

Open
luser opened this issue Jul 20, 2018 · 4 comments
Open

Provide a way to specify configuration for host compilation #5754

luser opened this issue Jul 20, 2018 · 4 comments
Labels
A-configuration Area: cargo config files and env vars S-triage Status: This issue is waiting on initial triage.

Comments

@luser
Copy link
Contributor

luser commented Jul 20, 2018

cargo currently supports specifying configuration per-target. Unfortunately, for non-cross-compiles this can lead to undesirable behavior. For example, we build Firefox in many variant configurations, several of which involve passing compiler and linker options that are useful for target binaries but cause problems when used for building things like build scripts. The simplest example here is address sanitizer--we want to compile and link with -fsanitize=address, but linking build scripts with that means they're now running with asan and that's not something we want to do. We have the same problem with our code coverage builds, which compile and link with --coverage.

It would be better if we had a way to explicitly configure host compilation. The simplest proposal I can think of would be to support [host.$triple] keys in config files and use those for host compilation.

@alexcrichton
Copy link
Member

Thanks for this report and #5755 @luser, this is definitely not something that was expected to come up! Out of curiosity, when you compile in Gecko are you doing cargo build --target $host or are you just doing cargo build? I wrote up recently some comments about how those "naively equivalent" invocations are actually subtly different in Cargo today.

That is, I think we could pretty easily do something like this for cargo build --target $host as Cargo already understands if a compilation is for the host (build scripts, proc macros, etc) or the target. It'd be quite easy to add an env var like CARGO_KIND=host or CARGO_KIND=target (or something like that).

If, however cargo build is used (without --target) then this situation gets a bit more tricky...

In any case, if Cargo supports this environment variable I think it'd be totally reasonable for cc to not use environment variables if CARGO_KIND=host and HOST == TARGET. Or rather, in those cases it'd perhaps have a whole different suite of env vars if really necessary it'd read from for the host.

@alexcrichton
Copy link
Member

Oh actually I guess most of that comment would be more appropriate on #5755 rather than here! (I think I'm getting the two mixed up).

For Cargo's configuration do you use [target.$target] today for linker/rustflags/etc? Which parts are needed to configure for the host compilation (but not target)?

@luser
Copy link
Contributor Author

luser commented Jul 23, 2018

We always pass --target to cargo in the Firefox build. For things like the linker, we currently pass them all as environment variables when invoking cargo. We do have a few things in .cargo/config, including a path to a batch file to use as a linker when we're building a win32 build with a win64 rustc (which is similar to what this issue is about, but simpler because the target and host are not the same).

@ehuss ehuss added the A-configuration Area: cargo config files and env vars label Feb 21, 2019
@kaimast
Copy link

kaimast commented Oct 5, 2019

How do you set RUST_HOST_TARGET in your script? Is there an easy way to detect this?

Ideally if rust is invoked without a target it should build with the host target but it seems to build with the last target used for me :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-configuration Area: cargo config files and env vars S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

5 participants