wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (11/15/89)
In article <12551@cit-vax.Caltech.Edu> tim@cit-vax.UUCP (Timothy L. Kay) writes: >The only symptom I find is that xemacs doesn't work under X windows, >but temacs does. I am running Interactive 386/ix on a 386 clone. Yes, I can confirm this problem. Vitals: ATT 6386 (PC clone) ATT SysV /bin/cc ISC "port" X11r3 Interlan Network code Firstly Interlan and ISC need to get their acts together. The two binary-only "commercial quality" packages don't work well enough to even run a normal X program over the network! Secondly even on a local system, xemacs dumps core in (emacs) select(). The problem is that emacs select gets called with timeout_pointer == 0 from XKeyReadable() [quoted from memory]. Hacking emacs select to understand null-pointer timeouts (via treating it as *timeout == 10000) causes an infinate-polling loop from XkeyReadable(). I have no ISC sources, so I am tempted to punt. Lets Stamp out this binary bullshit! -wolfgang Wolfgang Rupprecht ARPA: wolfgang@mgm.mit.edu (IP 18.82.0.114) TEL: (703) 768-2640 UUCP: mit-eddie!mgm.mit.edu!wolfgang
tim@cit-vax.Caltech.Edu (Timothy L. Kay) (11/18/89)
In article tim@cit-vax.UUCP (Timothy L. Kay) writes: >The only symptom I find is that xemacs doesn't work under X windows, >but temacs does. I am running Interactive 386/ix on a 386 clone. In article wolfgang@BBN.COM (Wolfgang Rupprecht) writes: >Secondly even on a local system, xemacs dumps core in (emacs) select(). I was the first poster, and I have solved my problem. There is (almost) nothing wrong with either Emacs or Interactive Unix. It was simply a mistake in configuring Emacs. If you add the line #include HAVE_SELECT to the config.h, then the program working fine. The problem is that RMS's select() is only partially functional, and he documented it as such in the code. If you try to use this one, then anything else that uses select() (such as X window's library) won't work. But, Interactive supplied a select(), so there is really no problem. Actually, there is a minor problem. It would have been better if the Emacs' select() function had been named my_select(). Then, if HAVE_SELECT was undefined, we would get an undefined reference error rather than results that almost work and seem to point the finger at the Unix implementation. Also, I think it would be nice to have a program that pokes around in Unix (like the one that comes with less) and automatically creates a config.h. Such a program should be possible, and could work well enough that you could get rid of all the s-*.h and m-*.h files. Perhaps I'll write one. Tim
james@raid.dell.com (James Van Artsdalen) (11/21/89)
In <12551@cit-vax.Caltech.Edu>, tim@cit-vax.UUCP (Timothy L. Kay) wrote: > There is a comment in the etc/MACHINES file that shared libraries > do not work with emacs in 18.55. Who's comment is this? I'd like > to discuss the problem and see if I can be of some help fixing it. I fixed this a while back, but RMS wants me to get my company to disclaim the changes, and I haven't done it yet. The problem is that unexec.c doesn't really know about COFF and doesn't copy over the sections used to control shared libraries. I can mail the fix to anyone who wants it. -- James R. Van Artsdalen james@raid.dell.com "Live Free or Die" DCC Corporation 9505 Arboretum Blvd Austin TX 78759 512-338-8789