Re: trying to solve some missing symbols during linking (porting to Plan9)

[Jens Staal]

On Fri, Oct 11, 2024 at 04:01:10AM -0500, G. Branden Robinson wrote:
> Hi Jens,
> 
> At 2024-10-11T10:49:34+0200, Jens Staal wrote:
> > Dear Branden,
> > 
> > Apparently did I not get the reply in my mailbox (I guess I would have
> > to be subscribed to the channel). Your hunch was true it seems, when I
> > included the termcap object files among the bash object files during
> > linking (in a way to force early linking with termcap), the error
> > message disappeared.
> > 
> > I do not have ncurses on Plan9, but PDCursesMod. It only has some stub
> > functions in its term.h, however.
> 
> Right.  My understanding of that project and its ancestor suggests to me
> that PDCursesMod is not going to be much help for bash; it expects a
> real terminal device (at least in its interactive operation mode).
> PDCurses and PDCursesMod are designed to expose the curses API to
> graphical windowing systems.  That is, they expect to be used with some
> kind of rectangular GUI canvas "widget", which they can then treat as a
> sort of ersatz terminal.
>

Thanks for letting me know. It probably saved me from going to the
rabbithole of trying to use libedit and pdcursesmod as alternatives to
readline and ncurses.

> > I now have a binary. Unfortunately it crashes immediately after
> > execution so there are certainly things to fix/troubleshoot...
> > 
> > I did not "hack" much in the source except including <limits.h> a bit
> > higher up in several source files because the compiler kept
> > complaining that CHAR_MAX and UCHAR_MAX were re-defined.
> > 
> > I tried compiling with both jobs and nojobs, and both resulting
> > binaries crashed, so it does not seem to be job control that is the
> > problem.
> 
> It may in fact be.  The design of process groups and session leaders and
> the interaction of these with signals is deeply entwined with the Unix
> terminal model.  That can, I suspect, have knock-on effects when the
> "terminal" is a GUI canvas as mentioned above.
> 

OK that is a bit discouraging. I had hoped that the crashing of the
"nojobs" build would be an indication that job control is not the issue.
(for mksh, the -DNOPROSPECTOFWORK which disabled job control made that
shell build)

> We're getting beyond my competence here; I've read W. Richard Stevens
> but I haven't mastered these matters, and I have a gnawing fear that the
> only people who have are those who have written Unix shells that other
> people have used.
> 

I am also way out of my depth. Hopefully someone much smarter than me
will come up with a good suggestion.

> You may need further assistance from the help-bash list.  Please feel
> free to quote my response there.
> 

Thanks. I have CCd the help-bash list again here. I also just saw
another reply suggesting to build without readline. I will try that and
see what happens.

> Regards,
> Branden