[In a build from yesterday's CVS, I have again an unexpected blank
gutter in this message-mode buffer. I'm not sure how it happened, but
this is not the first time. ... More info. ... When I switch virtual
consoles (in WindowMaker) and return to the XEmacs virtual console,
the buttons reappear. After hitting C-l (sometimes it is taking
multiple presses), they promptly disappeared again, see attached
screen dumps. This is at best intermittent because most of the time
it does not happen.]
Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org:
>>>>> "Glynn" == Glynn Clements
<glynn(a)sensei.co.uk> writes:
...
Glynn> This indicates that the Xaw headers used for compilation
Glynn> don't match the libXaw.so which is being used at run-time
Glynn> (e.g. compiling with vanilla Xaw headers but using the
Glynn> libXaw.so from Xaw3d).
This is still happening to me ... I've confirmed (using
CPPFLAGS=-H)
that I'm getting the right headers ... ldd src/xemacs tells me I'm
getting the right library ... but bogosity rules!!
Aha!
Debian (unstable == potato, current as of a couple days ago)
supplies
both the standard libXaw.so and a libXaw3d.so, by those names, in
/usr/X11R6/lib. This is unlikely to go away since there are several
programs that don't seem to coexist with Athena 3D for some reason.
`ln -sf libXaw3d.so.6.1 libXaw.so' and bingo! no errors. But I
don't
think I want to do this permanently.
Or do I? (Advice, please.)
If not, Would it be reasonable for ./configure (once it has decided
to use Xaw3d) to test for the existence of libXaw3d.so (and maybe
libXaw3d.a, but maybe not) and do `-lXaw3d' instead of `-lXaw' in
that case?
That might be reasonable now. Does Debian also include fuckage[1] in the
form of having Xaw3d includes in <X11/Xaw3d>?
[Gutter bogosity snapshots]
Footnotes:
[1] Like, for example, TurboLinux does.