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.

[Mark-Simulacrum]

Closing -- I think a general issue such as this isn't really helpful and just adds noise. If there are concrete proposals for improvement here they can be filed as new issues, or even better PRs. We can't detect the build triple with 100% fidelity ever anyway.

[glaubitz]

I don't think it's a good idea to close bug reports when the bug itself hasn't been resolved yet. And I don't see how a single valid bug report produces noise when there are already 5000 open issues.

The underlying problem is that uname was/is being used to determine the architecture which is an unreliable mechanism. An idea might be to use getconf LONG_BIT to determine the bitness on top of the architecture.

[Mark-Simulacrum]

I would open a dedicated bug about the bitness issue; generally speaking more specific bugs are better. I closed this one in part because it was quite broad (and as such not concretely actionable).