Re: 11.0_BETA amd64 build aborted at `checkflist'

[Van Ly <van.ly%SDF.ORG@localhost>]

"Greg A. Woods" <woods%planix.ca@localhost> writes:

> [1:text/plain Hide]
>
> At Sun, 07 Dec 2025 11:05:04 +0000, Van Ly <van.ly%SDF.ORG@localhost> wrote:
> Subject: Re: 11.0_BETA amd64 build aborted at `checkflist'
>>
>>
>> These are the environment variables [1] before calling [2].  I've set
>> `no' to the MKDEBUG, MKDEBUGKERNEL, MKDEBUGLIB options.  See how it
>> goes.
>
> Note there's a very complete way to view and confirm the values of all
> of the relevant build.sh runtime parameters, both those from the
> environment, as well as any from the build.sh command line:
>
>      ./build.sh [[ all your settings ]] show-params



Thanks.



> Also, script(1) is probably the most complicated and way to capture a
> log of output from "build.sh", and potentially can lead to weird things
> happening if there's ever a bug in the build that tries to do something
> interactive whenever there a TTY is still attached to a STDIO descriptor.
> It could also potentially slow down your build as everything still has
> to be written through the [p]TTY device you're using.
>
> I just do, effectively, "./build.sh >> build.log 2>&1 &" and then I can
> run "tail -f build.log" if I want to follow along.



Yes, I should do it this way.  Previously, I was relying on the emacs shell buffer to capture the session and then used the script(1) wrapper to keep a file copy.



> This separates the writing of output to the log file from the writing of
> the same to the TTY ensuring slow TTY output doesn't slow down the build.
>
> The only tricky part of doing it that way is you have to remember to
> explictly kill the build.sh background job if you want to interrupt it.
>
> You can also run build.sh in the background with nohup(1), which
> effectively does the same thing with redirecting output, and will keep
> running if you happen to be disconnected from the shell session where
> you started it, though it has a hard-coded log file name ("nohup.out" in
> the current working directory).



Does a shell session inside tmux(1) also provide that continuity behavior?



> In my build.sh wrapper script I actually do the redirect with "exec" so
> that I can nohup the whole thing and at the same time get a custom name
> for the log file.  All that goes to "nohup.out" is the "Now logging
> to..."  message.
>
> if ! ${DEBUG} && ! ${NO_EXEC}; then
> 	if ${DO_REBUILD} && ! ${NO_EXEC}; then
> 		> $LOGFILE
> 	fi
> 	if ${LOG_IT}; then
> 		echo ""
> 		echo "Now logging to $LOGFILE"
> 		echo ""
> 		exec 1>> $LOGFILE 2>&1
> 	fi
> fi
> if ${DEBUG} && ${LOG_IT}; then
> 	echo ""
> 	echo "Would be logging to $LOGFILE"
> 	echo ""
> fi
>


Thanks.



-- 
vl