Old build of rustup-init for netbsd fails to find current executable

[lambda]

If I run the recommended install instructions on NetBSD 8, I get an error complaining about not being able to find the current working directory (there are also some problems with escape characters on my terminal, but let's not worry about those right now):

$ uname -a
NetBSD faeroes 8.0_STABLE NetBSD 8.0_STABLE (GENERIC) #0: Mon Sep 10 17:56:49 UTC 2018  [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC amd64

$ curl https://sh.rustup.rs -sSf | sh
info: downloading installer
$<2>
Welcome to Rust!
$<2>
This will download and install the official compiler for the Rust programming
language, and its package manager, Cargo.

It will add the $<2>cargo$<2>, $<2>rustc$<2>, $<2>rustup$<2> and other commands to Cargo's bin
directory, located at:

  /sdf/udd/a/annodomini/.cargo/bin

This path will then be added to your $<2>PATH$<2> environment variable by modifying the
profile file located at:

  /sdf/udd/a/annodomini/.profile

You can uninstall at any time with $<2>rustup self uninstall$<2> and these changes will
be reverted.

Current installation options:

$<2>   $<2>default host triple: $<2>x86_64-unknown-netbsd$<2>
$<2>     $<2>default toolchain: $<2>stable$<2>
  modify PATH variable: $<2>yes$<2>

1) Proceed with installation (default)
2) Customize installation
3) Cancel installation
1

$<2>error: $<2>could not locate working directory
$<2>info: $<2>caused by: No such file or directory (os error 2)

Checking the version, I find we're running an old build of rustup-init:

$ curl https://sh.rustup.rs -sSf > rustup.sh

$ sh rustup.sh -V
info: downloading installer
rustup-init 1.11.0 (e751ff9f8 2018-02-13)

Checking the code, this error can actually occur not just because of an error in locating the working directory, but also in locating the current executable; this should probably be fixed to provide a better error message:

        LocatingWorkingDir {
            description("could not locate working directory")
        }

pub fn current_dir() -> Result<PathBuf> {
    env::current_dir().chain_err(|| ErrorKind::LocatingWorkingDir)
}

pub fn current_exe() -> Result<PathBuf> {
    env::current_exe().chain_err(|| ErrorKind::LocatingWorkingDir)
}

If we ktruss the rustup-init process, we see that the __getcwd called by curret_dir succeeds, it's actually the current_exe call that's failing:

$ ktruss -id sh rustup.sh
...
 11324      1 rustup-init __getcwd(0x7bb5b0d56200, 0x200) = 22
 11324      1 rustup-init readlink("/proc/curproc/exe", 0x7bb5b0d4d100, 0x100) Err#2 ENOENT
...

In libstd 1.24.0, the netbsd platform was changed to prefer using a sysctl call rather than reading from /proc/curproc/exe, which is less reliable; rust-lang/rust@ccef9696:

NetBSD: add sysctl backend for std::env::current_exe

Use the CTL_KERN.KERN_PROC_ARGS.-1.KERN_PROC_PATHNAME sysctl in
preference over the /proc/curproc/exe symlink.

Additionally, perform more validation of aformentioned symlink.
Particularly on pre-8.x NetBSD this symlink will point to '/' when
accurate information is unavailable.

However, based on the ktruss results it looks like rustup-init was build with a toolchain prior to this fix.

There are a couple of things that would help to address this issue:

1. Start building rustup-init for NetBSD again; I haven't been able to figure out exactly what pieces of the CI setup would need to be changed for this, but I suspect a new build with a new Rust toolchain would fix this issue.
2. Distinguish the error messages for failure to find working directory from failure to find current executable; it would have saved a bit of digging with ktruss during the debugging process
3. Don't rely on being able to find the current executable path; it's not always possible to do so reliably on all platforms. rustup-init.sh could instead pass in the path to the current executable, since it knows where it downloaded it to and is executing it from.

I'm not sure if the third point is worth doing if the other two are addressed, but it would probably be the most robust solution.

[iquiw]

I was going to open new issue about old rustup version on NetBSD, and found this issue.

I did not see the error (on NetBSD 9.99.10), but rustup version is still 1.11.0 on NetBSD.

$ rustup self update
info: checking for self-updates
info: downloading self-update
info: rustup updated successfully to 1.11.0

Is there any point I can check?

[kinnison]

NetBSD is not currently supported as a rustup release platform at all. If you can come up with a PR which adds support to our build matrix then we can carry it for unsupported use by intrepid players such as yourself.

[iquiw]

@kinnison @alexcrichton I'm sorry for bothering you.
Just want to clarify (not complaining) about supported platform.

I thought NetBSD was supported.
NetBSD target was in .travis.yml before and x86_64-unknown-netbsd is currently listed in "Other installation methods" in README.

So NetBSD became unsupported at some point? Or it has never been supported officially?

Thank you.

[kinnison]

I think it was never properly supported, but at one point we managed to do a build. I guess we need to either clean up README to not mislead people into thinking it's releasable; or, more usefully, we need to sort out a fresh builder for it. If you fancy having a go at updating our .travis.yml to support netbsd once more, then I'd be pleased to look at the resulting PR.

[iquiw]

Thank you for the reply!!
I see the situation.

I am trying to setup Travis CI build for NetBSD target (based on stable branch). But it failed at linking phase.
https://travis-ci.org/iquiw/rustup.rs/jobs/577379337

I am afraid it is beyond my knowledge. I will continue to investigate it though.

[iquiw]

rustup on NetBSD is the latest now!!

$ rustup self update
info: checking for self-updates
info: downloading self-update
info: rustup updated successfully to 1.19.0

$ rustup --version
rustup 1.19.0 (2af131cf9 2019-09-08)

@lambda Please try it if possible.

[kinnison]

If this is no good for @lambda then this can be re-opened. For now, I'm going to close it.