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: MIT shared memory extension
This is off-topic for the xfree mailing list, it's really a developer or
general topic. Anyway
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 10, 2002 5:36 AM
Robert Collins wrote:
In short, I don't like the idea of making key_t 32 bits.
I have taken deeper into ftok and have some questions:
The current implementation (excuse the indenting):
key_t
ftok (const char *path, int id)
{
struct stat statbuf;
if (stat (path, statbuf))
return (key_t) -1;
/* dev_t is short
* ino_t is long
* and we need 8 bits for the id
*/
return ((long long) statbuf.st_dev (5*8)) | (statbuf.st_ino (8)
) | (id 0x00ff);
}
1. Why do you use st_dev explicity. Isn't ftok() only for
files ? From the ftok documentation: The ftok() function
returns a key based on path and id that is usable in
subsequent calls to msgget(), semget() and shmget(). The path
argument must be the pathname of an existing file that the
process is able to stat().
So st_dev seems to make no sense for me and could be removed.
Possibly. If the file can be stat'd - and devices can - we should check
it, no?
2. Does st_ino creates uniq inodes rsp. hash values ? If so,
why not (CASE1) adding an ascii representation of id to the
path and calling hash_path_name() (the function which creates
statbuf.st_ino) or (CASE2), using id as hash value for
hash_path_name() like the following code.
hashs collide. key_t's can not collide under any circumstance, and must
be deterministic (i.e. not dependent on currently issued keys).
How do you suggest that you avoid hash collisions?
Rob
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: MIT shared memory extension
This is off-topic for the xfree mailing list, it's really a developer or general topic. Anyway Should we move this to the cygwin list ? I'm not subscribed to the develop list. 1. Why do you use st_dev explicity. Isn't ftok() only for files ? From the ftok documentation: The ftok() function returns a key based on path and id that is usable in subsequent calls to msgget(), semget() and shmget(). The path argument must be the pathname of an existing file that the process is able to stat(). So st_dev seems to make no sense for me and could be removed. Possibly. If the file can be stat'd - and devices can - we should check it, no? Yes, this can be done after the stat() call. 2. Does st_ino creates uniq inodes rsp. hash values ? If so, why not (CASE1) adding an ascii representation of id to the path and calling hash_path_name() (the function which creates statbuf.st_ino) or (CASE2), using id as hash value for hash_path_name() like the following code. hashs collide. key_t's can not collide under any circumstance, and must be deterministic (i.e. not dependent on currently issued keys). But how do you ensure this in the current implementation ? st_ino contains a hash value. So this problem concerns the current implementation and the suggestion I've made. How do you suggest that you avoid hash collisions? With my suggestion I haven't adressed the problem of avoiding hash collisions. I only have addressed the newlib patch you suppose. Sorry :-( BTW: I have additional looked into the cygipc implementation. They uses only the lower word of st_ino and lowest byte of st_dev and lowest byte of id. And this seems to work, although the must have this hash collision problem even more, doesn't it ? May be this is another way to prevent the newlib patch. Regards Ralf
Re: Any hope to get xkb extension working?
Olaf Frczyk wrote: Hi, Has anyone found why setxkbmap is not working in XFree86 4.2.0? Regards, Olaf Fraczyk Perhaps the same reason why xsetroot is not working too ;) But why ?- Cpm. -- Christian P. MOMON ONE2TEAM RD [EMAIL PROTECTED]
RE: Best place for WindowMaker, Openbox, etc.?
Harold Hunt wrote: Hmm... the problem I'm running into with fvwm95 is that I can't do a build from a directory other than the source root Probably true. I didn't look into it more than being able to compile and run from the source directory. IIRC, I still got a number of warnings about DLL auto-imports and the like. I didn't even try changing the prefix from /usr/local. (I'm no autotools expert, either.) I was building from a complete Cygwin installation--with all of the tools kept current but without extension libraries/etc. from other sources. BTW, WindowMaker exits with a SEGV on our systems. I haven't looked into it, but verified the problem on multiple systems so it's not isolated to my machine (all IBM laptops running Win2K/Cygwin, though). In all cases, wmaker begins to run and starts creating icons, etc., then throws up a screen reporting that it received a signal 11. I haven't had time to look into it yet. (I got similar behavior from X11 GVIM until I rebuilt it specifically excluding GTK, although that's probably just a coincidence.) The other window managers in the Cygwin dist (openbox, twm) run fine. Fvwm95 seems to work, but I haven't really been using it (before I put much effort into tweaking it, I'd like to check out some other window managers). -Jerry -O Gerald S. Williams, 55A-134A-E : mailto:[EMAIL PROTECTED] O- -O AGERE SYSTEMS, 6755 SNOWDRIFT RD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18106-9353: mobile:908-672-7592 O-
RE: Unable to get french keyboard with XDMCP connexion on AIX
On Thu, 9 May 2002, Harold Hunt wrote: Frederic, Well, after about a week of discussion on this topic I'd just like to summarize the project's standpoint on this issue: 1) We would love to have great internationalization support in Cygwin/XFree86. XFree86 has i18n support. XKB was build for this. But it seems AIX hasn't. 2) No one currently on the project seems to have both the time and knowledge to provide such internationalization support (some have the time, others have the knowledge, but no one seems to have both :) As soon as I got some free time, I'll cleanup those config-file patches and post them for checking them, but they will only help for OSs where XKB is working. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 phone: +49 3725 349 80 80 mobile: +49 172 7854017 4. Chemnitzer Linux-Tag http://www.tu-chemnitz.de/linux/tag/lt4
Re: Any hope to get xkb extension working?
On 2002.05.10 16:11 Alexander Gottwald wrote: On Fri, 10 May 2002, Olaf Fr±czyk wrote: Hi, Has anyone found why setxkbmap is not working in XFree86 4.2.0? You either don't have the xkb files installed or /tmp is not mounted binary. But maybe a more detailed problem description give us a hint. This is problem which was reported earlier on this list (25 April) by Edmund Urbani. Here I a part of his mail: Yesterday i installed cygwin with XFree 4.2.0. Everything worked fine from the start except that I could not set it up for my german keyboard layout. All I get, when I try to use eg. setxkbmap is a popup window (outside the X server as a normal Win2000-window) with this error message: Failed assertion fds_on_hold !=NULL at line 643 of file /cygnus/netrel/src/cygwin-1.3.10-1/winsup/cygwin/dtable.cc (End of quoted mail) So, I have exactly the same problem. When I moved /usr/X11R6 and /etc/X11 from another instalation with 4.1.0 everything works fine. So I have to stay with 4.1.0 as setting keyboard layout from command line when starting X is not solution for me. Regards, Olaf
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: Best place for WindowMaker, Openbox, etc.?
Ton van Overbeek, I suspect that the real solution here would be for me to link Cygwin's automode.o into WindowMaker, thus allowing WindowMaker to run regardless of the mount type of $HOME/GNUstep/. I'll see what I can do about that... Harold Ton van Overbeek [EMAIL PROTECTED] said: Gerald Williams wrote: BTW, WindowMaker exits with a SEGV on our systems. I haven't looked into it, but verified the problem on multiple systems so it's not isolated to my machine (all IBM laptops running Win2K/Cygwin, though). In all cases, wmaker begins to run and starts creating icons, etc., then throws up a screen reporting that it received a signal 11. I haven't had time to look into it yet. Had the smae behaviour on W98SE. WindowMaker copies its config files to the user home directory ($HOME/GNUstep/...). If this directory is not binary mounted you get the signal 11. Probably the reading code in WindowMaker opens the config files in binary mode and then gets confused by the \r\n combinations it gets from a text mounted filesystem. If you mount the home directory as binary, no signal 11 and WindowMaker works fine. Ton van Overbeek
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: Xinerame ?
Philippe, As far as I know, Xinerama provides multiple screen support for XFree86. I was never able to find much documentation about Xinerama. However, *you* need to explain to *me* why using XFree86's hardware-level multiple screen support would provide any benefit (or even make sense) for Cygwin/XFree86, which has no direct access to the hardware. From what I know about Xinerama (and I could be missing something about Xinerama) it has absolutely no application to Cygwin/XFree86. Harold Philippe Bastiani [EMAIL PROTECTED] said: Why Xinerama seems not supported by Cygwin/XFree86 ? I found no reference to the library relating to this XFree86 feature... Philippe Bastiani
Re: Xinerame ?
Hi, Someone recently put me on to Virtual Desktop which is free ($) software that might interest those with a craving for screen real estate (there never is enough, is there?). Neither of us has tried it with XFree86, however, so if someone here does, please report your experiences to the list. http://www.enablesoftware.com/ Virtual Desktop is the last item listed on the page. Randall Schulz Mountain View, CA USA At 13:32 2002-05-10, Harold L Hunt wrote: Philippe, As far as I know, Xinerama provides multiple screen support for XFree86. I was never able to find much documentation about Xinerama. However, *you* need to explain to *me* why using XFree86's hardware-level multiple screen support would provide any benefit (or even make sense) for Cygwin/XFree86, which has no direct access to the hardware. From what I know about Xinerama (and I could be missing something about Xinerama) it has absolutely no application to Cygwin/XFree86. Harold Philippe Bastiani [EMAIL PROTECTED] said: Why Xinerama seems not supported by Cygwin/XFree86 ? I found no reference to the library relating to this XFree86 feature... Philippe Bastiani
Re: Xinerame ?
On Sat, May 11, 2002 12:05:41AM +0200, Wilhelm Person wrote: Downloaded and installed it. Isn't free, the version on the page is a 30-day trial $20 for one without a nag screen. Anyway.. It appears to work with Cygwin, but I had some problems when running XFree86 in fullscreen mode on win2k (fullscreen doesn't work with the virtual desktops very well it seems.) I don't know how much functionality you're after, but more than one window manager supports multiple desktops. Personally I'm kind of minimalist -- I use fvwm2 with one desktop three screens wide. It works fine fullscreen. DeskTopSize 3x1 # screens wide x tall EdgeResistance 0 0 EdgeScroll 3 3
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:Cygwin/XFree86 logged into KDE3 causes strange Cygwin error
I had similar problems and have solved them by installing all XFree components (I thing the Xserver with frame buffer helps) The main thing was to reduce the colours from 32 bit to 16 bit on the windows 2000 Laptop (IBM ThinkPad E23) Now I am happy and can work on the Linux Server with KDE3 and German Keyboard settings via kdm. This is a planed solution for some scientists, which need an graphical access from windows 2000 Laptops to a Linux-cluster with Splus and other applications. regards Heiner Speth -Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 08, 2002 2:15 PM To: Speth, Heiner PH/DE Subject: RE: XDM from Cygwin Heiner, The solution is for you to ask this question at [EMAIL PROTECTED], where I have forwarded this email. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 08, 2002 5:31 AM To: [EMAIL PROTECTED] Subject: XDM from Cygwin Hello I have read your mail. Do you have a solution for this problem. I am trying to install additional fonts on cygwin Xfree and hop that this helps. An access to an KDE 2 Server works fine. Regards Heiner Speth
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
