Support cross-compile install

[infinity0]

I can't get a cross-compiled install to work, it keeps installing the build (native) architecture's binaries and libraries instead of the host (foreign) architecture binaries and libraries. Even if I do ./x.py dist --install --host $HOST --target $TARGET these extra flags just get ignored.

As an example, cross-compiling from a build machine x86_64 to a foreign host aarch64:

$ file build/aarch64-unknown-linux-gnu/stage2/bin/rustc 
build/aarch64-unknown-linux-gnu/stage2/bin/rustc: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=8d7ac7fba3b40cd623567a15f250a9c397d5a063, not stripped
[..]
$ DESTDIR=/build/rustc-mIBviY/rustc-1.17.0+dfsg2/debian/tmp ./x.py dist --config debian/config.toml -v --host aarch64-unknown-linux-gnu --target aarch64-unknown-linux-gnu --install
[..]
bootstrap top targets:
	Step { name: "install", stage: 2, host: "x86_64-unknown-linux-gnu", target: "x86_64-unknown-linux-gnu" }

It looks like this is hardcoded into step.rs:

            sbuild: Step {
                stage: build.flags.stage.unwrap_or(2),
                target: &build.config.build,
                host: &build.config.build,
                name: "",
            },

It would be good if a cross-compile install were possible. Otherwise I'd have to manually hack up some custom install scripts to install the files directly from build/aarch64-unknown-linux-gnu/stage2/.

[cuviper]

How about using the dist tarballs? You already ran ./x.py dist, so you can find them in ./build/dist/ with proper installers. That's basically all that ./x.py install uses anyway. Their contents are probably even still unpacked in ./build/tmp/dist/.

[infinity0]

That also works for the time being, but it's not clear to me whether if the layout or build-location of the tarballs will change in the future. (For example, the install command has already changed from dist --install to install between 1.17 and master.) The install interface is what's documented in README.md and src/bootstrap/README.md and the dist interface is less well-documented.

On Debian a native-build works by running sbuild rustc_$version.dsc, and a cross-build works just by adding a --host=$foreign flag - so from this perspective it's more kludgy to use two different install processes for native vs cross builds.

If I get firm instructions from rust here to "yes, ignore install and just extract the tarballs" then of course I'll do this, but it's not clear at the moment what is the preferred way to do a cross-built staged install.

For the time being I'm using the patch below, which I wrote before I saw your reply:

diff --git a/src/bootstrap/step.rs b/src/bootstrap/step.rs
--- a/src/bootstrap/step.rs
+++ b/src/bootstrap/step.rs
@@ -899,11 +899,15 @@ pub struct Rules<'a> {
 
 impl<'a> Rules<'a> {
     fn new(build: &'a Build) -> Rules<'a> {
+        let target = ::std::env::var("DEB_HOST_RUST_TYPE").unwrap();
+        // rust forces us to do this dance because of lifetimes :/
+        let hosts = &build.config.host;
+        let tidx = hosts.iter().position(|x| x == target.as_str()).unwrap();
         Rules {
             build: build,
             sbuild: Step {
                 stage: build.flags.stage.unwrap_or(2),
-                target: &build.config.build,
+                target: hosts[tidx].as_str(),
                 host: &build.config.build,
                 name: "",
             },

There might be a tidier way of doing this, I couldn't figure out how to make the envvar have the correct lifetime so I pulled the equivalent object off config.host.

[infinity0]

I suppose this is similar in spirit to rust-lang/cargo#3810.