nedit-5.3, Cygwin
For building nedit-5.3 (or 5.1.1) in Cygwin 1.3.12 with XFree86 4.2.0 and lesstif 0.93.18, change /usr/X11R6.4/ to /usr/X11R6/ in makefiles/Makefile.cygwin, lines 10 and 12 (or 5 and 7 in nedit-5.1.1). ([EMAIL PROTECTED]: I am not subscribed to this mailing list)
Troubles using XFree86-Xaw3d-1.5-1
Some months ago I built xfig with an easily self-compiled static libXaw3d.a. Now after installing XFree86-Xaw3d-1.5-1, I rebuilt xfig. This failed with a plenty of errors indicating multiple entry-point definitions (from Xaw3d and Xt) and auto-import errors (with respect to SME). The X libraries used were -lXpm -lXaw3d -lXmu -lXt -lXext -lX11 . Tentatively I omitted -lXt, which did not work either, resulting in an excessive list of other auto-import errors. Similar errors were reported before under subject Problems with libXaw3d [Was: [ITP] FreeCiv-1.12.0-1 for X
lesstif confuses app-defaults
After upgrading XFree86 and installing lesstif (so far, I had used my own lesstif), I found that the directory tree was confused: instead of a symlink /usr/X11R6/lib/X11/app-defaults - /etc/X11/app-defaults, there was a directory /usr/X11R6/lib/X11/app-defaults containing a symlink app-defaults and a file Mwm (the latter should rather have been in /etc/X11/app-defaults). Thus no application (except mwm) could find its app-defaults file. This is obviously a bug in the lesstif tar file. (I just found this effect has been reported before in 2002-05/msf00296.html but is still not fixed.)
X11 backing store
If X11 graphics programs request backing store, for instance, with drawattr.backing_store = Always; XChangeWindowAttributes(display, drawable, CWBackingStore, drawattr); this seems to have no effect. The same program works correctly in Solaris (SPARC) and IRIX (MIPS). The memory of my graphics card (8 MB, Rage Mobility) appears sufficient, since the whole screen would only use 2.3 MB with 24 bits/pixel. It would be desirable to have this possibility to avoid explicit redrawing after a portion of the window has been covered or the window has been iconized and reopened.
xterm title not shown
The title of xterm defined with option -T or -title does not appear in the title bar, instead the current directory is shown there. I do not know whether this is a problem of xterm or the window manager, but it happens both with twm and mwm.
RE: lesstif mwm bug
From: Harold L Hunt [EMAIL PROTECTED] This is sort of a 'growing pain'. We'll be following the Cygwin standard of using the /usr prefix. I had discussed this on the list with Chris Faylor and others and the conclusion was to use /usr as the prefix. We will only change this is some difficult problem arises for which there is no other solution than to change the prefix for all the XFree86 packages. From your statement I guess that prefix seems to have a different meaning for XFree86 and Lesstif. Using prefix=/usr/X11R6 would install Lesstif in the same directories as the XFree86 packages.
RE: lesstif mwm bug
From: Harold Hunt [EMAIL PROTECTED]
I'd like you to do two things for me so that I can correct the lesstif
package:
1) Please recompile lesstif and write down the exact set of configure flags
that allow lesstif to function correctly. Try compiling without
the --enable-static --disable-shared flags and see if the result still
works.
The flags mentioned by me were those I have used. First I had omitted
--enable-static --disable-shared, but building failed. Also the file
Install says:
On windows using Cygwin, U/WIN or Interix, LessTif must be built as
static libraries.
Because, one of the biggest issues with X on Win32 is the moronic DLL
format. Specifically - it is not possible to export data from a Win32
DLL in a form that can be used to statically initialize another global
variable. Data access from a DLL requires at least one pointer
indirection, and hence executable code. This is why X11R6 doesn't have
DLLs for Xt/Xmu/Xaw (and Motif) on Win32.
Unfortunately, configure does not force --enable-static --disable-shared
automatically for Cygwin.
2) Download the lesstif binary distribution for Cygwin from
http://prdownloads.sourceforge.net/lesstif/lesstiif-cygwin-0.93.18.tar.bz2.
See if their package works, then figure out if they built static or shared
libs.
They built static libs only; but it will take some days before I can install
and test their package on my PC (I just unpacked it on a Solaris host for
looking at it.)
They obviously used --prefix=/usr/X11R6, whereas you seem to have used /usr
and I have used none (=/usr/local). Their libraries are very large (libXm.a
is 18.8 MB), thus seem to contain debugging information.
*** Here another correction to my previous mail which stated:
In my case, it says that ~/.mwmrc is missing. Are system.mwmrc and Mwm in the
right places (/usr/X11R6/lib/X11/mwm/system.mwmrc,
/usr/X11R6/lib/X11/app-defaults/Mwm)?
system.mwmrc is in ${prefix}/lib/X11/mwm/, thus in /usr/lib/X11/mwm/ for
your package. For app-defaults, however, my statement was correct.
Re: lesstif mwm bug
From: Hans Werner Strube [EMAIL PROTECTED] The mwm from lesstif eats up 99 % of CPU time, both in the binary package and in a self-compiled version. I found that the select() calls in events.c do not wait but immediately fail with errno = EBADF, although fd_width is 256 and x_fd is 3 or 4 (printed out in mwm.c). I have not yet found the reason, only a dirty workaround: Replace the select by usleep(1). Now I found the reason of the bug. Whereas fd_width is 256, FD_SETSIZE (the number of bits in fd_set variables) is only 64, so that select() tests for unpredictable file descriptors from 64 to 255. For mwm, as x_fd has low values, it will be sufficient to limit fd_width in mwm.c: if(fd_width FD_SETSIZE) fd_width = FD_SETSIZE; More generally, the value of FD_SETSIZE in /usr/include/sys/types.h should be increased (as the comments say, to = NOFILE from param.h)!
lesstif mwm bug
The mwm from lesstif eats up 99 % of CPU time, both in the binary package and in a self-compiled version. I found that the select() calls in events.c do not wait but immediately fail with errno = EBADF, although fd_width is 256 and x_fd is 3 or 4 (printed out in mwm.c). I have not yet found the reason, only a dirty workaround: Replace the select by usleep(1).
Re: Shell survives killing xterm
From strube Mon Mar 18 11:27:45 2002 When an xterm (running bash) is killed, e.g. by twm menu or by exiting the xinitrc, the bash survives in the background with PPID 1 and has to be killed manually with kill -HUP. The only way to exit xterm neatly seems to be calling exit in its shell. This is very annoying. Is there a workaround? As the man page of bash says SIGTERM and SIGQUIT are ignored by an interactive bash, I tried setting trap exit 0 TERM QUIT in .bashrc, but without success. The same happens with tcsh.
ssh2 in xterm problem
I have the Windows version of ssh2 (SSHWinClient-3.1.0-build235 from ssh.com) installed. Besides the Windows GUI client, there is also a command line client ssh2. This works well from the Cygwin login shell. But when I call it from an xterm shell in XFree86-4.2.0, the password prompt appears not in this shell but in the login shell from which X was started. I tried to enter the password there but without any effect. When I enter the password in the xterm, it is echoed and has no effect either. What is the reason for this strange behaviour, and can it be circumvented? (Well, don't tell me I could install openssh; this seems to indicate a basic problem to be solved!)
