rustbuild: if stage0 binaries can't be run, kindly inform user

[cengiz-io]

Hello!

I was trying to build rust within Alpine linux and since it comes with musl instead of glibc I've bumped into this confusing error message from rustbuild.

$ make check
Traceback (most recent call last):
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 614, in <module>
    main()
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 602, in main
    bootstrap()
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 587, in bootstrap
    rb.build_bootstrap()
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 377, in build_bootstrap
    self.run(args, env)
  File "/home/test/rust/src/bootstrap/bootstrap.py", line 380, in run
    proc = subprocess.Popen(args, env=env)
  File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
make: *** [Makefile:54: check] Error 1

cargo is there, in stage0 directory but since it's not compatible with musl. execution fails.

My proposal is (thanks @matt36 for the idea) that we should catch the error and inform the user with more context.

$ make check
/home/test/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo could not be executed.

You might want to check your internet connection stability since it might be preventing
you from getting stage0 packages correctly.

If the archives are intact, then please check your operating system compatibility on prebuilt 
stage0 binaries. 

Go to: http://docs.rust-lang.org/some/docs/here for more information.

Build completed unsuccessfully in 0:00:00
make: *** [Makefile:54: check] Error 127

(If you're wondering "why cargo is not found?" please refer to #31322)

Thanks

[matt36]

There is a downside to adding shell=True to the subprocess.Popen call: it creates the potential for the script to be vulnerable to a 'shell injection' - see https://docs.python.org/2/library/subprocess.html#frequently-used-arguments

The security risks of this might be minimal (I'm not very familiar with the bootstrap process), or could be mitigated by correctly escaping the arguments passed to the shell.

In this particular case it would probably be simpler to improve the bootstrap.py script to catch this exception and improve the error message instead.

[cengiz-io]

In this particular case it would probably be simpler to improve the bootstrap.py script to catch this exception and improve the error message instead.

That sounds so much better.

[cengiz-io]

Hello @alexcrichton!

(Moving the discussion into issue)

Yes, I know that musl is not directly supported. But I'm throwing ideas right now.

Instead of changing it to a shell (like I did), I think we can catch the error and report it with more context, like

Execution error: /path/bin/cargo could not be run. Please check your _______
What do you think?

[alexcrichton]

@cengizio that sounds totally plausible to me!

[Enselic]

Triage: Since musl binaries have been shipped for many years now, we can probably close this as won't fix? If not, in what realistic scenario would a user benefit from this feature being implemented?