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
Huh? Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans Werner Strube Sent: Saturday, May 11, 2002 5:18 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 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
At 22:26 5/10/2002 -0400, Harold Hunt wrote: This also means that my mwm.exe problems have nothing to do with shared libs (since I've only been building static libs). One interesting thing to note is that I can get mwm to switch between virtual desktops by moving the mouse pointer to the edge of the screen. The window redraws correctly for the new virtual desktop and I can navigate back to the original desktop. However, I cannot move, resize, etc. the xterm window. I've seen this too. Mwm and/or X gets confused about the state of NumLock. Just hit NumLock once and everything works. Hope this helps. Ton van Overbeek
RE: lesstif mwm bug
Ton van Overbeek, Thanks. This indicates that the mwm.exe bug has nothing to do with LessTif. In fact, this indicates is a problem with the way that Cygwin/XFree86 treats the NumLock key and possibly other modifier keys. As a test I just compiled XWin.exe with a modified xc/programs/Xserver/hw/xwin/winkeybd.c/winGetKeyMappings () function that has these lines removed: case XK_Num_Lock: pModMap[i] = NumLockMask; break; Pulling those lines out causes mwm.exe to have no problems, regardless of the state of the NumLock key. Of course, the NumLock key no longer functions in Cygwin/XFree86, but what can you do? :) I'm going to go ahead and release the new LessTif packages that use /usr/X11R6 as the prefix and I'm going to see if I can fix the way that XWin.exe handles NumLock, etc. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ton van Overbeek Sent: Saturday, May 11, 2002 8:28 AM To: Harold Hunt; [EMAIL PROTECTED] Subject: RE: lesstif mwm bug At 22:26 5/10/2002 -0400, Harold Hunt wrote: This also means that my mwm.exe problems have nothing to do with shared libs (since I've only been building static libs). One interesting thing to note is that I can get mwm to switch between virtual desktops by moving the mouse pointer to the edge of the screen. The window redraws correctly for the new virtual desktop and I can navigate back to the original desktop. However, I cannot move, resize, etc. the xterm window. I've seen this too. Mwm and/or X gets confused about the state of NumLock. Just hit NumLock once and everything works. Hope this helps. Ton van Overbeek
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
Hans Werner Strube wrote: 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. Some more information about mwm.exe in lesstiif-cygwin-0.93.18.tar.bz2. The mwm.exe in that package (/usr/X11R6/bin/mwm.exe) needs the following dll's: libICE.dll, libSM.dll, libX11.dll, libXext.dll, cygwin1.dll and KERNEL32.dll. So obviously it has linked libXm and other needed libraries statically. Also this mwm.exe has the 100% CPU-time bug when idle. One other thing: please keep the lesstif cygwin packages (on sourceforge and the 'official' cygwin-XFree86 package) synchronised: i.e agree on same prefix etc. Maybe the sourceforge page should point to the official cygwin-XFree86 package in the future. I do not want to end up with mwm.exe in both /usr/bin and /usr/X11R6/bin and libXm.a, libMrm.a and libUil.a in both /usr/lib and /usr/X11R6/lib. Ton van Overbeek
RE: lesstif mwm bug
Ton van Overbeek, Some more information about mwm.exe in lesstiif-cygwin-0.93.18.tar.bz2. The mwm.exe in that package (/usr/X11R6/bin/mwm.exe) needs the following dll's: libICE.dll, libSM.dll, libX11.dll, libXext.dll, cygwin1.dll and KERNEL32.dll. So obviously it has linked libXm and other needed libraries statically. Excellent point. I hadn't thought to look at the dependencies of mwm.exe. I will rebuild the LessTif package, hopefully tonight, to use static libraries for now. Also this mwm.exe has the 100% CPU-time bug when idle. That's good to know. Interesting that no one complained before. There must not have been many people using LessTif's MWM on Cygwin before the setup.exe package was created. One other thing: please keep the lesstif cygwin packages (on sourceforge and the 'official' cygwin-XFree86 package) synchronised: i.e agree on same prefix etc. Maybe the sourceforge page should point to the official cygwin-XFree86 package in the future. I do not want to end up with mwm.exe in both /usr/bin and /usr/X11R6/bin and libXm.a, libMrm.a and libUil.a in both /usr/lib and /usr/X11R6/lib. 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. After we get the static LessTif package released, and a few people confirm that it works, I will contact the LessTif folks to let them know that binaries for Cygwin are being distributed via setup.exe and that they can add a link to the Cygwin home page instead of distributing Cygwin binaries. Harold
Re: lesstif mwm bug
On Fri, May 10, 2002 at 02:41:03PM -0400, Harold L Hunt wrote: One other thing: please keep the lesstif cygwin packages (on sourceforge and the 'official' cygwin-XFree86 package) synchronised: i.e agree on same prefix etc. Maybe the sourceforge page should point to the official cygwin-XFree86 package in the future. I do not want to end up with mwm.exe in both /usr/bin and /usr/X11R6/bin and libXm.a, libMrm.a and libUil.a in both /usr/lib and /usr/X11R6/lib. 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. I don't think I ever gave an opinion on the /usr/bin vs. /usr/X11R6/bin. My preference is that all official X stuff goes in /usr/X11R6/bin but that seems to be counter to the way most modern distributions do things. So, I don't know that we have an actual policy. cgf
Re: lesstif mwm bug
I'm told that the Debian policy is that for historical reasons, stuff from x.org goes in /usr/X11R6, but other stuff, even if it uses X, goes in /usr/bin.
Re: lesstif mwm bug
Christopher Faylor wrote: I don't think I ever gave an opinion on the /usr/bin vs. /usr/X11R6/bin. My preference is that all official X stuff goes in /usr/X11R6/bin but that seems to be counter to the way most modern distributions do things. So, I don't know that we have an actual policy. I was one of the main proponents of all the other dists put everything into /usr/bin, so we should too. Earnie raised the issue about binaries that can exist as either X- or MS-native-windowing, but not simultaneously as both in a single executable (e.g. rxvt). I said fuhgeddaboutit until we actually SEE the problem. And then I saw the problem. tcl/tk. The cygwin version that is currently distributed uses MS-native windowing, for lots of very good reasons. It is installed into /usr/bin, /usr/include, /usr/lib. But what if I want to build an X-based application with tk? I'd need a X-based tk -- which obviously cannot go into /usr/bin, /usr/include, and /usr/lib. So, now I think that REGARDLESS of what those other distributions do, we should segregate X- linked apps and libraries into /usr/X11R6/. Very few other platforms have multiple windowing environments to deal with. The closest similarities I can think of are: 1) X- and terminal-. Two common solutions: a) single binary, operates in either mode (FSF-Emacs) b) two different binaries with different names (vim, gvim) 2) X- and svgalib-. a) Two different binaries with the same name; only one may be installed on a system at a time (Mandrake's graphical Aurora bootup) b) two different binaries with different names () 3) regular X and gtk a) two different binaries with the same name; only one installed on the system at a given time (XEmacs. In fact, Mandrake for instance ONLY provides the gtk version; the normal X- version is no longer available officially). But, these are all VERY rare. Of the thousands of apps out there, most are JUST terminal, or JUST X-, or JUST svgalib. The conflicts just haven't happened often enough for the distributions to come up with a cohesive plan -- they just seem to special case the rare conflicts. I think Earnie's right: these problems will not be rare for us. We want native-windowing apps, and we want X-windowing apps, and sometimes, we want the same program in either/both/ forms (tk, XEmacs, rxvt, gtk(?), etc). To see a real comparison between what they do and what we do, imagine what would happen if Berlin or W or another 2nd-generation X became really popular... So, finally, in summary, IMO, X- linked apps should be compiled and installed with --prefix=/usr/X11R6/ --Chuck
RE: lesstif mwm bug
Ton van Overbeek, Some more information about mwm.exe in lesstiif-cygwin-0.93.18.tar.bz2. The mwm.exe in that package (/usr/X11R6/bin/mwm.exe) needs the following dll's: libICE.dll, libSM.dll, libX11.dll, libXext.dll, cygwin1.dll and KERNEL32.dll. So obviously it has linked libXm and other needed libraries statically. Also this mwm.exe has the 100% CPU-time bug when idle. Hmm... I just rebuilt the LessTif package using --enable-static --disable-shared and installed it. I still get the same problem where mwm runs and doesn't have the 100% CPU-time but, but it still doesn't do anything when I click things (other than make the button flash). I ran cygcheck on this new mwm.exe and got: $ cygcheck mwm.exe Found: C:\cygwin\bin\mwm.exe C:\cygwin\bin\mwm.exe .\libICE.dll C:\cygwin\bin\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL .\libSM.dll .\libX11.dll .\libXext.dll So the libraries are indeed static in the new LessTif that I just built. However, I became curious so I uninstalled the new LessTif (0.93.18-3) and reinstalled the supposed shared library version of LessTif (0.93.18-2). I then ran cygcheck on this old mwm.exe and, lo, got the same results: $ cygcheck mwm.exe Found: .\mwm.exe .\mwm.exe .\libICE.dll C:\cygwin\bin\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL .\libSM.dll .\libX11.dll .\libXext.dll Thus the default settings for building LessTif on Cygwin must be to build static libs only. Therefore the LessTif 0.93.18-2 Cygwin package has static libs. This also means that my mwm.exe problems have nothing to do with shared libs (since I've only been building static libs). One interesting thing to note is that I can get mwm to switch between virtual desktops by moving the mouse pointer to the edge of the screen. The window redraws correctly for the new virtual desktop and I can navigate back to the original desktop. However, I cannot move, resize, etc. the xterm window. Finally, I switched the prefix from /usr to /usr/X11R6. I don't want to release this new package until we can figure out why mwm isn't working for me (as it will probably do the same for others). Harold
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)!
Re: lesstif mwm bug
On Tue, May 07, 2002 at 09:21:52AM +0200, Hans Werner Strube wrote: 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)! You can set this up yourself if it is important to you. Just define FD_SETSIZE before including sys/types.h. cgf
Re: lesstif mwm bug
I'll try to patch the LessTif package tonight and get it uploaded. Harold Christopher Faylor [EMAIL PROTECTED] said: On Tue, May 07, 2002 at 09:21:52AM +0200, Hans Werner Strube wrote: 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)! You can set this up yourself if it is important to you. Just define FD_SETSIZE before including sys/types.h. cgf
