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