Autodetection of build triple doesn't work in some cases

[metux]

downloading https://static.rust-lang.org/dist/2017-06-15/rust-std-beta-x86_64-unknown-linux-gnu.tar.gz
######################################################################## 100,0%
extracting /home/nekrad/src/rust/1/rust/build/cache/2017-06-15/rust-std-beta-x86_64-unknown-linux-gnu.tar.gz
downloading https://static.rust-lang.org/dist/2017-06-15/rustc-beta-x86_64-unknown-linux-gnu.tar.gz
######################################################################## 100,0%
extracting /home/nekrad/src/rust/1/rust/build/cache/2017-06-15/rustc-beta-x86_64-unknown-linux-gnu.tar.gz
downloading https://static.rust-lang.org/dist/2017-06-15/cargo-beta-x86_64-unknown-linux-gnu.tar.gz
######################################################################## 100,0%
extracting /home/nekrad/src/rust/1/rust/build/cache/2017-06-15/cargo-beta-x86_64-unknown-linux-gnu.tar.gz
Traceback (most recent call last):
File "./x.py", line 20, in
bootstrap.main()
File "/home/nekrad/src/rust/1/rust/src/bootstrap/bootstrap.py", line 694, in main
bootstrap()
File "/home/nekrad/src/rust/1/rust/src/bootstrap/bootstrap.py", line 675, in bootstrap
rb.build_bootstrap()
File "/home/nekrad/src/rust/1/rust/src/bootstrap/bootstrap.py", line 423, in build_bootstrap
run(args, env=env, verbose=self.verbose)
File "/home/nekrad/src/rust/1/rust/src/bootstrap/bootstrap.py", line 142, in run
ret = subprocess.Popen(args, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 710, in init
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

(devuan)nekrad@orion:~/src/rust/1/rust$ dpkg --print-architecture
i386

(devuan)nekrad@orion:~/src/rust/1/rust$ gcc -dumpmachine
i586-linux-gnu

[codyps]

@metux what does uname -a print on that system?

[metux]

Linux orion 4.4.0-79-generic #100~14.04.1-Ubuntu SMP Fri May 19 18:36:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

But it is wrong for buildsystems to just silently rely on parsing uname (instead of asking the target toolchain), w/o even providing an option to override.

[kennytm]

@metux You should be able override by setting the build, host and target in your config.toml. You could also pass the --build, --host and --target flags to x.py.

[metux]

Tried that, of course, but didn't work.
I had to hack up x.py to remove the broken uname call.

Looking at uname -a is completely wrong to begin with, as it doesn't tell you anything about the target platform (it's just the host kernel's cpu type). Except trivial cases, you'll guess wrong.
You gotta ask the target compiler (the one passed via $CC) for the correct target tuple.

[kennytm]

@metux Have you really tried the config.toml approach? If your config.toml contains the line

build = "i586-unknown-linux-gnu"

it should work, otherwise it is a bug in the bootstrap system. You may need to delete the whole build/ directory first, otherwise it will reuse the old, wrong stage0.

(It ignores the --build flag though, which I consider a bug.)

Analyzing bootstrap.py

bootstrap.py (x.py)'s stage0 URL is computed as

            filename = "rust-std-{}-{}.tar.gz".format(
                rustc_channel, self.build)

where build is assigned as

 rb.build = rb.build_triple()

where build_triple() is defined as

    def build_triple(self):
        default_encoding = sys.getdefaultencoding()
        config = self.get_toml('build')
        if config:
            return config
        config = self.get_mk('CFG_BUILD')
        if config:
            return config
        try:
            ostype = subprocess.check_output(['uname', '-s']).strip().decode(default_encoding)
            ....

So it will first check your config.toml, before falling back to uname-checking.

[codyps]

(It ignores the --build flag though, which I consider a bug.)

#38198

[glaubitz]

It's generally a bad idea to use "uname" to detect the build architecture as the kernel does not necessarily have the same bitness as the userland.

Other popular examples are:

• sparc64 kernel with a sparc userland
• ppc64 kernel with a powerpc userland
• arm64 kernel with an armhf userland

I just ran into this particular issue while trying to build rustc for Debian powerpc on a machine with a 64-bit kernel and 32-bit userland.