Re: still can't get X going on 9.2

[steve%prd.co.uk@localhost (Steve Blinkhorn)]

OK, some real progress, thanks to your suggestion of ssh'ing from
another machine.

Running xterm this way:
/usr/X11R7/lib/libXrender.so.2: Undefined PLT symbol "_XGetRequest"
(symnum = 54)

Similarly, running ctwm:
/usr/X11R7/lib/libXext.so.7: Undefined PLT symbol "_XGetRequest"
(symnum = 98)

Yet all the library files come straight from the X sets and bear a
date of May 12 2021.

I have to say I've been plagued by this kind of error message in the
past, trying and failing to get firefox working.  But I haven't been
able to work out where _XGetRequest is meant to be defined.  But xterm
and window managers didn't seem to invoke it prior to this release.

--
Steve Blinkhorn <steve%prd.co.uk@localhost>

You wrote:
> 
> > If I just run:
> 
> > %X :0
> 
> > I get the X background and cursor, but no xterm.
> 
> That's exactly what you should get in that circumstance.  You haven't
> started any clients, so there are no clients.
> 
> xinit, when operating normally, starts clients after the server is up.
> If you are running things manually, you will have to start any clients
> you want yourself.
> 
> Personally, I'd suggest coming over ssh twice from another machine.
> First session, start the X server; second session, start a client, with
> a suitable DISPLAY in the environment (probably DISPLAY=:0).  xterm is
> a reasonable choice.  Errors, if any, may or may not show up anywhere
> in particular, but the second session seems to me like the most likely
> place to see them.
> 
> If you're concerned about your .xinitrc, then tell xinit to what start
> instead.  You may need to change the paths, but aside from that this
> would probably be something like
> 
> xinit /usr/X11R7/bin/xterm -- /usr/X11R7/bin/X
> 
> (I have a fuzzy memory that xinit wants full paths on its pathname
> arguments, but that memory could be confused.  Personally, I'd put a
> path on xinit itself, too, but that's because I usually don't have
> /usr/X11R7/bin in my path.)
> 
> If you really can't see anything, then I'd suggest using ktrace on
> either just the xterm run (when, eg, coming in over ssh) or, if the
> issue arises only with xinit, on the shell (ktrace -i -d -p $SHELLPID,
> loosely put) that runs xinit.  But do the ktrace as root - this is
> port-amd64, and, while I have a fuzzy memory that this may have changed
> recently, some parts of X on i386 and amd64 (and others?) have
> historically needed privilege and thus can't usefully be ktraced except
> by root.
> 
> The resulting trace is likely to be voluminous.  But if you kdump each
> process into its own file and look at the one for xterm, you may be
> able to see an unexpected error.
> 
> Just remember to use your root shell to ktrace -C after the test run,
> or everything that shell does will get appended to the trace.
> 
> If you see failures with both X and xterm run manually, you may be able
> to see something useful by running just xterm under ktrace.
> 
> /~\ The ASCII				  Mouse
> \ / Ribbon Campaign
>  X  Against HTML		mouse%rodents-montreal.org@localhost
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>