djs@nimbus3.UUCP (Doug) (02/05/90)
I've been trying to build GNU emacs 18.55 on an AT&T 6386 running System V/386 Release 3.2.2. In config.h I used m-intel386.h and s-usg5-3.h. In s-usg5-3.h, I defined HAVE_PTYS and SYSV_PTYS since the system seems to have them. During the build, the compile dies in sysdep.c because the include file <sys/sioctl.h> does not exist. I commented out the include line as suggested by a comment in sysdep.c. After doing that, the compile dies because it does not know the size of a struct named tchar. Also, I thought that I read a bug report that said that one of the source files needs to be built without the optimizer on or the resulting emacs will dump core. If anyone knows what the proper defines are to make this work and which file should not be compiled with the optimizer, I would really appreciate the information. -- Doug Scofea Email: osu-cis!nimbus3!djs Phone:(614) 794-2853
jackv@turnkey.gryphon.COM (Jack F. Vogel) (02/05/90)
In article <186@nimbus3.UUCP> djs@nimbus3.UUCP (Doug) writes: [....problems building emacs....] >During the build, the compile dies in sysdep.c because >the include file <sys/sioctl.h> does not exist. >I commented out the include line as suggested by >a comment in sysdep.c. After doing that, the compile dies because >it does not know the size of a struct named tchar. Here you go, create the file <sys/sioctl.h> with the following content: ----------------------------------------------------------------------- /* suplimental tty control character stuff */ struct tchars { char t_intrc; /* interrupt */ char t_quitc; /* quit */ char t_startc; /* start output */ char t_stopc; /* stop output */ char t_eofc; /* end-of-file */ char t_brkc; /* input delimiter (like nl) */ }; ----------------------------------------------------------------------- Should take care of your problem. Sorry, but I do not recall which file it was that was supposed to be compiled without optimization, but I imagine someone else out there will remember. Disclaimer: These views are mine, not necessarily LCC or IBM's -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
nvk@ddsw1.MCS.COM (Norman Kohn) (02/05/90)
In article <186@nimbus3.UUCP> djs@nimbus3.UUCP (Doug) writes: >I've been trying to build GNU emacs 18.55 on an AT&T 6386 running >System V/386 Release 3.2.2. In config.h I used m-intel386.h and >s-usg5-3.h. Try using m-is386.h Worked for me with no trouble (running under uport 386) -- Norman Kohn | ...ddsw1!nvk Chicago, Il. | days/ans svc: (312) 650-6840 | eves: (312) 373-0564
dwp@mtune.ATT.COM (David Preisler) (02/07/90)
In article <186@nimbus3.UUCP>, djs@nimbus3.UUCP (Doug) writes: > I've been trying to build GNU emacs 18.55 on an AT&T 6386 running > System V/386 Release 3.2.2. In config.h I used m-intel386.h and > s-usg5-3.h. In s-usg5-3.h, I defined HAVE_PTYS and SYSV_PTYS since > the system seems to have them. > > During the build, the compile dies in sysdep.c because > the include file <sys/sioctl.h> does not exist. > I commented out the include line as suggested by > a comment in sysdep.c. After doing that, the compile dies because > it does not know the size of a struct named tchar. > > ... > -- > Doug Scofea Email: osu-cis!nimbus3!djs Phone:(614) 794-2853 To find out what include file the structure is defined in you might try: find /usr/include -print -exec grep tchar {} \; | more If it does not succeed, you don't have the header file needed. thanks, David William Preisler System Administrator AT&T Bell Laboratories Email: att!mtune!dwp 200 Laurel Avenue Middletown, NJ 07748 Phone: (201) 957-2594
djs@nimbus3.UUCP (Doug) (02/07/90)
>In article <186@nimbus3.UUCP>, djs@nimbus3.UUCP (Doug) writes: > I've been trying to build GNU emacs 18.55 on an AT&T 6386 running > System V/386 Release 3.2.2. In config.h I used m-intel386.h and > s-usg5-3.h. In s-usg5-3.h, I defined HAVE_PTYS and SYSV_PTYS since > the system seems to have them. > > During the build, the compile dies in sysdep.c because > the include file <sys/sioctl.h> does not exist. > I commented out the include line as suggested by > a comment in sysdep.c. After doing that, the compile dies because > it does not know the size of a struct named tchar. Thanks to all that responed to my plea for help. Someone sent me email saying that the code in 18.55 was from before AT&T include pseudo-ttys in its distribution. They sent me several suggestions on how to get this to build. I made the following changes in sysdep.c: 1) I undefined TIOCGETC 2) I changed the sioctl.h include to be ptem.h 3) I also had to include stream.h for one of the structure definitions in ptem.h. After that, sysdep.c compiled. The build then died in process.c because <sys/pty.h> did not exist. After rooting around in the include files, I decided to change pty.h to ptms.h since it said it was the support for pseudo terminals. I also had to include stream.h. After these changes, it managed to build a somewhat working emacs. The emacs starts up and seems to be able to edit o.k. but has the following behaviors: 1) It will randomly die, logging me off the system (although this seems to only happen if I mess around with a subprocess). 2) The lisp variable process-connection-type is set to t, indicating that emacs thinks it's using pseudo ttys for process connections. 3) A process started with M-! will return output to the buffer. However, running the 'tty' command produces "Not a typewriter" error message. I thought that this should not happen with pseudo-tty connections. 4) Shell mode locks up the terminal. All characters typed do not appear anywhere. Hitting control-g produces the "Quit" on the status line but does not free up the terminal. Killing the sub-shell from another terminal shows that emacs catches the death of the child signal. The only way out of this is to kill the emacs process from another terminal. If anyone has any suggestions about what I can try to fix this I would really appreciate it. As you can probably tell, I know next to nothing about pseudo-ttys. -- Doug Scofea Email: nimbus3!djs@cis.ohio-state.edu Phone:(614) 794-2853
kittlitz@granite.cr.bull.com (Edward N. Kittlitz) (02/10/90)
I had a problem similar to 4 with my ESIX (V.3.2 derivative). I think the problem is in keyboard.c, where it is trying to read process output. The system calls (don't have source in front of me) which are trying to determine whether or not there is a character available are returning 0 characters available. My shell was working because a command like "echo foo > /tmp/test" created the file. I fiddled the code to lie under some circumstances, and the output started arriving. On a similar note, am I way out in left field or what? in process.c, it seems that system V code ends up trying to open the same device for child and parent. can't remember which is which, but it gets a name like /dev/ttyp0 and uses that both ways. I fiddled and got the child to open the other end (/dev/ptyp0), and it worked. Hoping I'm not fibbing because I'm not looking at source...
kittlitz@granite.cr.bull.com (Edward N. Kittlitz) (02/10/90)
yet another problem I have encountered with my ESIX (V.3.2 derivative). my beast has shared library implementations of nsl_s, but no unshared version is in evidence. It appears that unexec does not cope with .lib sections. this only seems to matter when I build an X version. I've started to attempt to deal with this - has anyone done so successfully?
keffer@milton.acs.washington.edu (Thomas Keffer) (03/13/90)
In article <302@mtune.ATT.COM> dwp@mtune.ATT.COM (David Preisler) writes: >In article <186@nimbus3.UUCP>, djs@nimbus3.UUCP (Doug) writes: >> I've been trying to build GNU emacs 18.55 on an AT&T 6386 running >> System V/386 Release 3.2.2. In config.h I used m-intel386.h and >> s-usg5-3.h. In s-usg5-3.h, I defined HAVE_PTYS and SYSV_PTYS since >> the system seems to have them. >> >> During the build, the compile dies in sysdep.c because >> the include file <sys/sioctl.h> does not exist. >> I commented out the include line as suggested by >> a comment in sysdep.c. After doing that, the compile dies because >> it does not know the size of a struct named tchar. >> >> ... >> -- >> Doug Scofea Email: osu-cis!nimbus3!djs Phone:(614) 794-2853 I, too, had this problem. The cure I used was to simply include #undef TIOCGETC somewhere around line 131, just after a similar declaration for XENIX. Everything compiled and worked fine after that. Now, if I could just switch the backspace and delete keys (not as simple as simply restructuring keyboard-translate-table which switches ^h and del, not the keys themselves). Suggestions? -tk --- Dr. Thomas Keffer | Internet: keffer@ocean.washington.edu Rogue Wave | BITNET: keffer%ocean.washington.edu@UWAVM Seattle, WA 98145-1341 | uucp: uw-beaver!ocean.washington.edu!keffer (206) 523-5831 | Telemail: T.KEFFER/OMNET