[linux] make install fails with 'could not canonicalize' if destination dir does not exist

[eddyp]

I managed to compile aver-rust from source on my Debian Stretch system, and with prefix=/home/eddy/opt/avr-rust-git, it fails to 'make install' with this cryptic error, if the directory does not exist:

eddy@aptonia:~/usr/src/rust/avr-rust/rust/build $ make install
Updating only changed submodules
Submodules updated in 0.02 seconds
    Finished dev [unoptimized] target(s) in 0.10s
thread 'main' panicked at 'could not canonicalize /home/eddy/opt/avr-rust-git', src/bootstrap/install.rs:74:48
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
failed to run: /home/eddy/usr/src/rust/avr-rust/rust/build/build/bootstrap/debug/bootstrap install
Build completed unsuccessfully in 0:00:01
Makefile:65: recipe for target 'install' failed
make: *** [install] Error 1

Same error with backtrace:

eddy@aptonia:~/usr/src/rust/avr-rust/rust/build $ (export RUST_BACKTRACE=1 ;make install)
Updating only changed submodules
Submodules updated in 0.02 seconds
    Finished dev [unoptimized] target(s) in 0.10s
thread 'main' panicked at 'could not canonicalize /home/eddy/opt/avr-rust-git', src/bootstrap/install.rs:74:48
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:336
   7: bootstrap::install::install_sh::{{closure}}::{{closure}}
             at src/bootstrap/install.rs:74
   8: core::result::Result<T,E>::unwrap_or_else
             at /rustc/3a5d62bd5675ddd406a5b93d630ba1ddced91777/src/libcore/result.rs:766
   9: bootstrap::install::install_sh::{{closure}}
             at src/bootstrap/install.rs:74
  10: core::option::Option<T>::map_or
             at /rustc/3a5d62bd5675ddd406a5b93d630ba1ddced91777/src/libcore/option.rs:437
  11: bootstrap::install::install_sh
             at src/bootstrap/install.rs:73
  12: bootstrap::install::install_std
             at src/bootstrap/install.rs:25
  13: <bootstrap::install::Std as bootstrap::builder::Step>::run
             at src/bootstrap/install.rs:201
  14: bootstrap::builder::Builder::ensure
             at src/bootstrap/builder.rs:1297
  15: <bootstrap::install::Std as bootstrap::builder::Step>::make_run
             at src/bootstrap/install.rs:177
  16: bootstrap::builder::StepDescription::maybe_run
             at src/bootstrap/builder.rs:183
  17: bootstrap::builder::StepDescription::run
             at src/bootstrap/builder.rs:207
  18: bootstrap::builder::Builder::run_step_descriptions
             at src/bootstrap/builder.rs:571
  19: bootstrap::builder::Builder::execute_cli
             at src/bootstrap/builder.rs:561
  20: bootstrap::Build::build
             at src/bootstrap/lib.rs:456
  21: bootstrap::main
             at src/bootstrap/bin/main.rs:17
  22: std::rt::lang_start::{{closure}}
             at /rustc/3a5d62bd5675ddd406a5b93d630ba1ddced91777/src/libstd/rt.rs:64
  23: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:293
  24: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:85
  25: std::rt::lang_start_internal
             at src/libstd/panicking.rs:272
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  26: std::rt::lang_start
             at /rustc/3a5d62bd5675ddd406a5b93d630ba1ddced91777/src/libstd/rt.rs:64
  27: main
  28: __libc_start_main
  29: _start
failed to run: /home/eddy/usr/src/rust/avr-rust/rust/build/build/bootstrap/debug/bootstrap install
Build completed unsuccessfully in 0:00:00
Makefile:65: recipe for target 'install' failed
make: *** [install] Error 1

But if I make the directory by hand, the cryptic error goes away and install starts:

eddy@aptonia:~/usr/src/rust/avr-rust/rust/build $ mkdir ~/opt/avr-rust-git
eddy@aptonia:~/usr/src/rust/avr-rust/rust/build $ make install
Updating only changed submodules
Submodules updated in 0.02 seconds
    Finished dev [unoptimized] target(s) in 0.10s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.12s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 test artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Copying stage0 test from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.12s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 codegen artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu, llvm)
    Finished release [optimized] target(s) in 0.10s
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
[...]

I'm unsure this is avr-rust specific, or applies to the official rustc, so I'm reporting here.

FYI, issue seems to be very similar to #131 / #135, so the macOS specific fix of extending the macOS doc was not useful for my case since I rightfully skipped the macOS part.

I'm thinking the part responsible by the install should try to create the prefix dir, and, if fails, complain with a decent error message, if failed.

[eddyp]

This seems to be relevant: https://github.com/rust-lang/rust/issues/40108

[dylanmckay]

This is strange - there shouldn't be any AVR-specific directory muckery going on, and by the looks of those PRs linked in #40108, all the fixes landed in April, with the current avr-rust master branching in June.

I'm thinking the part responsible by the install should try to create the prefix dir, and, if fails, complain with a decent error message, if failed.

I agree that in the meantime, it's not a bad idea to hack the build script to mkdir -p it in some fashion.

I wouldn't be surprised if this is fixed by a rebase on rust-lang/master anyway, with these kinds of issues usually being the kinds of ones that go away after we update.