Re: Rust amd64 build failure.

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

On 12/04/2023 23:17, 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.
>
> Well, yes and no.  I did notice that rust recently got the option
> to build with an external "already-installed" rust, which our
> package doesn't yet use.
>
> I thought that instead the referred-to rust was the one from the
> bootstrap kit, but that appears to be false.
>
> So I deinstalled rust, and started another native build on
> NetBSd/amd64 9.3, and it started the build proper with
>
> => Modifying libtool scripts to use pkgsrc libtool
> => Modifying libtool scripts to use pkgsrc depcomp
> ===> Building for rust-1.68.2
> pre-installed rustc not detected: [Errno 2] No such file or directory: 'rustc'
> falling back to auto-detect
> 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
>     Compiling libc v0.2.137
>     Compiling proc-macro2 v1.0.46
>     Compiling cfg-if v1.0.0
>     Compiling memchr v2.5.0
>
> so I do have "liftoff" for the build even without rust already
> installed, and my guess is that in one hour it'll be done.
Yes my machine gets as far as invoking the rust bootstrap.

I bet you are getting lucky and on your machine the call to isatty() 
isn't returning an odd errno value that the rustix library used by the 
bootstrap isn't expecting. Newer versions of the rustix code have 
stopped doing errno checking altogether in that function which would 
resolve my problem.

This failure is what's blocking my builds and can only be fixed by the 
bootstraps being rebuilt with a newer rustix library.

This is the where my build is failing:

---------------------
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
    }
}
-----------------------
I'm hitting the panic due to an errno of 45(EOPNOTSUPP) which that code 
is classing as unexpected on NetBSD.

I'm clearly not alone in this as the current version of the library has 
this as the same function:
-----------------------
pub(crate) fn isatty(fd: BorrowedFd<'_>) -> bool {
    // Use the return value of `isatty` alone. We don't check `errno` 
because
    // we return `bool` rather than `io::Result<bool>`, because we assume
    // `BorrrowedFd` protects us from `EBADF`, and any other reasonably
    // anticipated `errno` value would end up interpreted as “assume 
it's not a
    // terminal” anyway.
    unsafe { c::isatty(borrowed_fd(fd)) != 0 }
}
-----------------------
Which would work fine and correctly infer that I'm not running the 
compiler on a tty.

I know WHY I'm getting the errno of 45. My build process wants to 
capture the logs to a file as well as outputting them to the console. To 
do this in a shell script I have to use a pipe made by mkfifo so that I 
can also capture the error status of the build.

So I effectively do:
mkfifo /tmp/xxxx
tee -a logfile </tmp/xxxx &
make install >/tmp/pipe 2>&1
status=$?
rm /tmp/xxxx

If I just did the more conventional:
make install 2>&1 | tee -a logfile

I'd would the exit status of tee instead of the build meaning my script 
would be blissfully unaware of build failures. Some versions of /bin/sh 
have an option to change this behaviour but not all the systems I use 
this script on have that.

Mike