uri@morannon.watson.ibm.com (Uri Blumenthal) (12/01/89)
--------- Hello, I don't know if it is a bug, but the chances are... I could compile the whole thing (after massive work with the "include" files - it didn't know about <sys/stream.h>, <sys/time.h> and some others for UNIX V.3.2. Well, worst comes to worst, it can compile now, but it dies at the very beginning (no, it can't dump, so I had to set up #define CANNOT_DUMP). It goes down telling me "Fatal (10).". As I can guess, this means "Signal 10 - Bus Error". 'sdb' can't tell the exact place, but it seems that it dies INSIDE system lib call getcwd(), being called from sysdep.c. I tried to play with X11 and without - results are certainly the same. Any help possible? And besides, would switching back to Emacs 18.52 or 18.54 help me? Is there any existing port to a similar system? Thank you. Uri. uri@ibm.com ============ <Disclaimer>
pinkas@joker.intel.com (Israel Pinkas) (12/20/89)
In article <1989Nov30.203638.10968@arnor.uucp> uri@morannon.watson.ibm.com (Uri Blumenthal) writes: > I don't know if it is a bug, but the chances are... > > I could compile the whole thing (after massive work with > the "include" files - it didn't know about <sys/stream.h>, > <sys/time.h> and some others for UNIX V.3.2. > > Well, worst comes to worst, it can compile now, but it dies > at the very beginning (no, it can't dump, so I had to set > up #define CANNOT_DUMP). > > It goes down telling me "Fatal (10).". As I can guess, this > means "Signal 10 - Bus Error". 'sdb' can't tell the exact > place, but it seems that it dies INSIDE system lib call > getcwd(), being called from sysdep.c. I tried to play with > X11 and without - results are certainly the same. > > Any help possible? And besides, would switching back to Emacs > 18.52 or 18.54 help me? Is there any existing port to a similar > system? I just brought up 18.55 on my 302 running 5.3.2. It took a bit of work, but proof by existence is the best proof. First, you cannot use any libraries which are shared. On my system, this includes libX11_s.a. (The _s suffix is the convention for shared library names.) I found that I could not compile fns.c with the -O flag. I don't know why, but when I did, Emacs died in concat() with Error 11 whenever it tried to access things from the DOC file. (It appeared to read in the file without problems, but died looking up the string.) When compiled without the -O flag, everything is fine. I used the distributed m-intel386.h. I modified s-usg5-3.h to define HAVE_PTYS, SYSV_PTYS, and HAVE_SOCKETS. I also had to add: #define LIBS_MACHINE -lsocket (I have Lachman TCP installed. This should also work with Wollongong (sp?), but I haven't tested that.) I also had to modify a few files in the src directory. In particular, my system doesn't have <sys/pty.h> (needed in process.c when SYSV_PTYS is defined). I included <sys/stream.h> and <sys/ptms.h> instead and everything works. As I mentioned, I could not include X11 support. Dumping shared libraries is unsupported. Somebody once sent me patches to dump with shared libraries (or was it SunOS' dynamic libs), but I lost it. I also made the following chages to sysdep.c. As before, since there is no standard for include files and packages like TCP, you may or may not need all of these patches. The second patch is needed because my system does not have <sys/sioctl.> (The comment right above the include file mentions the problem.) The other patches are to get termio working. I had to include some extra files and my version of SysV calls the struct tc, not tchars. Enjoy, -Israel *** src/sysdep.c.dist Fri Dec 15 10:43:59 1989 --- src/sysdep.c Fri Dec 15 12:05:59 1989 *************** *** 112,117 **** --- 112,120 ---- #ifdef HAVE_TERMIO #include <termio.h> + #include <sys/ttold.h> + #include <sys/stream.h> + #include <sys/ptem.h> #undef TIOCGETP #define TIOCGETP TCGETA #undef TIOCSETN *************** *** 150,159 **** --- 153,164 ---- /* Some USG systems with TIOCGWINSZ need this file; some don't have it. We don't know how to distinguish them. If this #include gets an error, just delete it. */ + #if (0) #include <sys/sioctl.h> #endif #endif #endif + #endif #ifdef HAVE_TIMEVAL #ifdef HPUX #include <time.h> *************** *** 685,691 **** #endif /* TIOCGLTC */ #ifdef TIOCGETC ! struct tchars old_tchars; int old_lmode; int lmode; /* Current lmode value. */ --- 690,696 ---- #endif /* TIOCGLTC */ #ifdef TIOCGETC ! struct tc old_tchars; int old_lmode; int lmode; /* Current lmode value. */ *************** *** 706,712 **** static struct ltchars new_ltchars = {-1,-1,-1,-1,-1,-1}; #endif #ifdef TIOCGETC ! static struct tchars new_tchars = {-1,-1,-1,-1,-1,-1}; #endif init_sys_modes () --- 711,717 ---- static struct ltchars new_ltchars = {-1,-1,-1,-1,-1,-1}; #endif #ifdef TIOCGETC ! static struct tc new_tchars = {-1,-1,-1,-1,-1,-1}; #endif init_sys_modes () *************** *** 713,719 **** { TERMINAL sg; #ifdef TIOCGETC ! struct tchars tchars; #endif #ifdef VMS #if 0 --- 718,724 ---- { TERMINAL sg; #ifdef TIOCGETC ! struct tc tchars; #endif #ifdef VMS #if 0 -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas ARPA: pinkas%cadev4.intel.com@relay.cs.net CSNET: pinkas@cadev4.intel.com
pcg@aber-cs.UUCP (Piercarlo Grandi) (12/21/89)
In article <PINKAS.89Dec19174826@joker.intel.com> pinkas@joker.intel.com (Israel Pinkas) writes: [ problems installing emacs 18.55 on a 386 ] I found that I could not compile fns.c with the -O flag. I don't know why, but when I did, Emacs died in concat() with Error 11 whenever it tried to access things from the DOC file. (It appeared to read in the file without problems, but died looking up the string.) When compiled without the -O flag, everything is fine. More or less once a month I have to repeat: the 386 optimizer is fairly good, but it does by default *inline* bits of assembler code here and there, most notably concat. Unfortunately this breaks alloca(), so the solution is to turn off inlining on any source that uses alloca(). In other words you can use the following options: -O -W2,'-y 0' and you will have optimization without inlining, and alloca() will work. If you want to have an idea of which fancy optimization the 386 optimizer does, add -z to -y. Now, if only AT&T documented the zillion options for the optimizer, it would be nicer. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk