Re: Rust amd64 build failure.

[Mike Pumford <mpumford%mudcovered.org.uk@localhost>]

On 11/04/2023 21:54, Mike Pumford wrote:
> On 11/04/2023 21:01, Havard Eidnes wrote:
>
> > Well, what can I say, it builds for me -- this is natively on
> > NetBSD/amd64 9.3.  My build log doesn't contain the
> > "pre-installed rustc not detected" message -- it starts the build
> > proper with:
> >
> > ===> Building for rust-1.68.2
> > detected default triple x86_64-unknown-netbsd from pre-installed rustc
> > Building rustbuild
> > running: /usr/pkgsrc/lang/rust/work/rust-bootstrap/bin/cargo build 
> > --manifest-path 
> > /usr/pkgsrc/lang/rust/work/rustc-1.68.2-src/src/bootstrap/Cargo.toml 
> > --frozen
> Doesn't that mean you already have a rust setup installed on the system. 
> That's a circular dependency that's never going to work for anyone 
> starting fresh (which is what my chroot does).
>
> Since I sent my e-mail I've reproduced the same failure in a 10-BETA 
> chroot so its got nothing to do with libkver.
>
> Looking back at my last successful build which was of rust 1.66.1 The 
> logs show:
>
> ==> Building for rust-1.66.1
> pre-installed rustc not detected: [Errno 2] No such file or directory: 
> 'rustc'
> falling back to auto-detect
> Building rustbuild
> running: /comp/obj/pkgsrc/lang/rust/work/rust-bootstrap/bin/cargo build 
> --manifest-path 
> /comp/obj/pkgsrc/lang/rust/work/rustc-1.66.1-src/src/bootstrap/Cargo.toml --frozen
>     Compiling libc v0.2.126
>     Compiling proc-macro2 v1.0.46
>     Compiling cfg-if v1.0.0
>
> So the lack of pre-installed rust is not a problem.
>
> Digging a bit deeper into the failing log I spotted:
>
> thread 'main' panicked at 'unexpected error from isatty: 45', 
> /cargo/registry/src/github.com-1ecc6299db9ec823/rustix-0.36.3/src/backend/libc/termios/syscalls.rs:141:20
>
> errno 45 is EOPNOTSUPP (operation not supported)
>
> Could the new rust be assuming that its running on a TTY device. This 
> isn't something that a compiler should be assuming.
I think this in the rustix library. Found the corresponding source code:

pub(crate) fn isatty(fd: BorrowedFd<'_>) -> bool {
    let res = unsafe { c::isatty(borrowed_fd(fd)) };
    if res == 0 {
        match errno().0 {
            #[cfg(not(any(target_os = "android", target_os = "linux")))]
            c::ENOTTY => false,

            // Old Linux versions reportedly return `EINVAL`.
            // <https://man7.org/linux/man-pages/man3/isatty.3.html#ERRORS>
            #[cfg(any(target_os = "android", target_os = "linux"))]
            c::ENOTTY | c::EINVAL => false,

            // Darwin mysteriously returns `EOPNOTSUPP` sometimes.
            #[cfg(any(target_os = "ios", target_os = "macos"))]
            c::EOPNOTSUPP => false,

            err => panic!("unexpected error from isatty: {:?}", err),
        }
    } else {
        true
    }
}

isatty is going to return 0. I'm not sure why it cares about the errno 
beyond that the file descriptor is not a tty if the call returns 0.

Not sure why isatty is returning EOPNOTSUPP when running under jenkins 
but its not something I have any control over and it worked prior to the 
last rust update.

So this is either a netbsd-10 bug or something that has to be dealt with 
in rust somehow.

Mike