toad@CS.CMU.EDU (Todd Kaufmann) (05/24/91)
In article <1991May21.213529.10223@bellcore.bellcore.com> schmidt@flash.bellcore.com (Robert O Schmidt) writes:
the need for the bogus include (errnet.h, mentioned in previous
posting) however did not go away (i dont know what this is
all about).
Me neither. I copied this file over from a '400, and when I got to this
point, did the following, explicitly including the place where I put the file:
src/emacs-18.57> (cd src; cc -g -Demacs -I/users/toad/hp-bogosity -c fileio.c)
I also had to copy of the X11 .h files!! How is anybody supposed to
compile an X program on these machines!??!? >!FLAME!< There isn't even a
debugger! (unless you count adb)
here however we ran into the same problem found on the vanilla
source:
cc: "unexhp9k800.c", line 84: error 1539: Cannot do arithmetic with
pointers to objects of unknown size.
When I got to this point (the first time), I thought I'd get the HUGE
version (Hp Unsupported Gnu Emacs), since it should work, right?also, this
looked like a hairy problem that I didn't want to spend time on.
So, I ftp'd it over (that took the rest of the night, over a transatlakntic
link (to Germany--by the way, I have a copy of HUGE at uni-erlangen, send
me mail if you want it));
Then, I had to kermit it over a couple of 9600pbs lins (another day to wait)
then I get the same problem. So, I resigned myself to looking at the C
code (really, i only do lisp), and found it was a simple type decl needed
here; change line 84 to read thus:
new_size = (long) sbrk(0) - auxhdr.exec_dmem;
[I just added the "(long)" in there], and then it compiles. However, I
don't know if it works, sinces the resulting dumped emacs starts up but
immediately produces an "Fatal error(11)." and doesn't make a window or
anything... I saw this before I think when I tried to build nepoch
on a rt with mach, and i think epoch on some sun too.. seems like dump problems.
Anyway, both HUGE and vanilla 18.57 will have these problems with
unexechp9k800.c. HUGE does have some extra goodies, like lots of extra
elisp, and highlighting with the mouse, though not anything like epoch
(which I'll be trying shortly, along with perl, tex, dvips, ghostscript,
etc).
So, I set CANNOT_DUMP, and it works. Even with all this to load, it only
takes about four seconds. When I add my environment (another meg or so of
elisp), that'll probably increse the start of time to about 5 seconds. To
compile all of emacs (not conunting the snags) is maybe five seconds.
Unbearable.
Well, now that I have emacs running it'll be much more livable environment.
Still, I feel like flaming for the crippled environment that HP ships with
this: No debugger! No X include files! I even waited a day before
posting (actually, the net went down), so I'm much more calmer now. But
I'm sure more refreshing irritants await me. But damn, they're fast.
yours in fumes,
todd kaufmann,
center for machine translation, currently on leave at
linguistische informatik, uni.erlangen, bavariarory@wri.com (Rory Murtagh) (05/24/91)
> ... > [I just added the "(long)" in there], and then it compiles. However, > I don't know if it works, sinces the resulting dumped emacs starts up > but immediately produces an "Fatal error(11)." and doesn't make a > window or anything... > ... The 720 uses shared libraries by default. This'll cause a problem. Try linking with : LDFLAGS = -a archive > ... > that HP ships with this: No debugger! No X include files! I even > ... man xdb xdb(1) xdb(1) NAME xdb - C, FORTRAN, Pascal, and C++ Symbolic Debugger ... - rory@wri.com
darrylo@hpnmdla.sr.hp.com (Darryl Okahata) (05/25/91)
In comp.sys.hp, toad@CS.CMU.EDU (Todd Kaufmann) writes: > Anyway, both HUGE and vanilla 18.57 will have these problems with > unexechp9k800.c. HUGE does have some extra goodies, like lots of extra [ I was hoping that I could restrict discussions like this to email .... ] When the "unofficial HP GNU Emacs" was released to INTEREX (to people outside Hewlett-Packard), an S700 box was not available for testing (and I still don't have access to such a beast). For those people who want to get either vanilla GNU Emacs or the "unofficial HP GNU Emacs" working on a snakes box, here is a copy of a posting from the help-gnu-emacs mailing list. All of the following patches should apply fine, with the possible exception of the patches to ymakefile (just apply them manually). Note that the author of the posting is *NOT* an HP employee. -- Darryl Okahata Internet: darrylo%sr@relay.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day. =============================================================================== Date: 07 May 91 13:01:59 PST To: help-gnu-emacs@prep.ai.mit.edu From: uunet.uu.net!mcsun!cernvax!rdm (Alphonse Rademakers) Subject: gnu emacs on hp 9000/720 From help-gnu-emacs-request@prep.ai.mit.edu Tue May 7 12: 31:32 1991 Organization: none Sender: help-gnu-emacs-request@prep.ai.mit.edu I got gnu emacs vsn 18.57 working on the HP 9000/720 by defining in the config.h the s-hpux.h and m-hp9000s800.h and by making the following mods in the files fileio.c, unexhp9k800.c and ymakefile. The most important change is to explicitely use the archive version of the libs and not the shared version. Cheers, Fons Rademakers. =========================== cut here ================= *** fileio.c.org Mon Mar 4 10:49:53 1991 --- fileio.c Mon Mar 4 10:50:12 1991 *************** *** 70,72 **** #include <netio.h> ! #include <errnet.h> #endif --- 70,72 ---- #include <netio.h> ! /* #include <errnet.h> */ #endif *** unexhp9k800.c.org Mon Mar 4 11:26:09 1991 --- unexhp9k800.c Mon Mar 4 15:41:17 1991 *************** *** 62,63 **** --- 62,64 ---- struct som_exec_auxhdr auxhdr; + long i; *************** *** 83,85 **** old_size = auxhdr.exec_dsize; ! new_size = sbrk(0) - auxhdr.exec_dmem; --- 84,87 ---- old_size = auxhdr.exec_dsize; ! i = (int *) sbrk(0); ! new_size = i - auxhdr.exec_dmem; *** ymakefile.org Mon Mar 18 16:33:41 1991 --- ymakefile Mon Mar 18 16:45:17 1991 *************** *** 98,100 **** #ifndef C_DEBUG_SWITCH ! #define C_DEBUG_SWITCH -g #endif --- 98,100 ---- #ifndef C_DEBUG_SWITCH ! #define C_DEBUG_SWITCH -g -I/usr/include/X11R4 #endif *************** *** 186,188 **** XOBJ = x11term.o x11fns.o ! LIBX = LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM #endif --- 186,188 ---- XOBJ = x11term.o x11fns.o ! LIBX = -L/usr/lib/X11R4 LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM #endif *************** *** 280,282 **** /* Construct full set of libraries to be linked. */ ! LIBES = LIBS_TERMCAP $(LIBX) LIBS_SYSTEM LIBS_MACHINE LIBS_DEBUG LIB_STANDARD $(GNULIB_VAR) --- 280,282 ---- /* Construct full set of libraries to be linked. */ ! LIBES = -a archive LIBS_TERMCAP $(LIBX) LIBS_SYSTEM LIBS_MACHINE LIBS_DEBUG L IB_STANDARD $(GNULIB_VAR) -- Org: CERN, European Organization for Nuclear Research. Mail: 1123 Geneve, Switzerland Fax: +22 7677155 Phone: +22 7674886 or 7675049 UUCP: rdm@cernapo.cern.ch BITNET: rdm@cernvm.bitnet