merce@iguana.uucp (Jim Mercer) (06/26/91)
i have compiled and run nethack3p9 on my 3b1.
i used gcc -traditional for all modules except monst.c which died in gcc
but was successful with the stock compiler.
the problem i have is that when i use the 's' search function, it dies.
grrr...
i just shelled out and tried it again, and it didn't die on me.
grrr.
however, in my several attempts to find secret doors at the end of a couple
dead end tunnels, the search function now appears not to work at all.
(the 1st level screen showed 3 rooms, all on the left side of the screen,
with one of the tunnels leading off to the right.)
wierd bug. has anyone else heard of this?
has anyone else build nethack3p{9,10} on a 3b1?
anyways, i am currently building 3p10 in hopes that it might go away.
i am also recompiling everything with gcc -traditional as i might have
compiled a few with the stock compiler.
i'll let you know what happens.
--
[ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ]
[ "If you've got the technology, you can party." Labatt's beer commercial ]wouk@alumni.colorado.edu (Arthur Wouk) (06/26/91)
if you do get it to run, please make it available at osu. -- arthur wouk internet: wouk@cs.colorado.edu
dt@yenta.alb.nm.us (David B. Thomas) (06/27/91)
wouk@alumni.colorado.edu (Arthur Wouk) writes: >if you do get it to run, please make it available at osu. I've already gotten mine to work. I used stock everything and it works fine. If someone wants to archive it, I'll pass it along. It's *big* though! I'd also be willing to snail-mail floppies of it to interested persons. The trick to getting it to make was defining STUPID_CPP. little david -- Early to rise and late to bed, Makes a man tired, wired, and dead.
dnichols@ceilidh.beartrack.com (DoN Nichols) (06/27/91)
In article <1991Jun26.041914.25466@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >i have compiled and run nethack3p9 on my 3b1. > >i used gcc -traditional for all modules except monst.c which died in gcc >but was successful with the stock compiler. > >the problem i have is that when i use the 's' search function, it dies. > >grrr... > >i just shelled out and tried it again, and it didn't die on me. > I have been being hit with this search bug, which is deadly if you are an elf, since they automatically use the search by their very nature. I have always been hit by it, till I just tried it by shelling out of trn, in which it now works. Since it doesn't dump core, it makes it hard to determine the source of the problem. The error message is: Memory fault I am running pl9 also. I've just been doing without the search command, and never playing as an elf. I tried to figure out what caused it when I first hit it with no success. That was a while ago, and I no longer have the sources on the system, since I've started getting netnews, I need the disk space :-) I hit the problem even if logged in via ethernet and rlogin, but if I shell out, from trn, or from jove, I don't. I wonder why? Lets try something! Shelling out from jove and doing: dnichols@ceilidh 203 > stty -a i get: speed cluster baud; line = 0; intr = ^c; quit = ^u; erase = DEL; kill = ^x; eof = ^d; eol = ^` -parenb -parodd cs8 -cstopb -hupcl -cread -clocal -ignbrk -brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc -ixon -ixany -ixoff isig icanon -xcase echo echoe echok -echonl -noflsh opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3 Going to another window and doing: dnichols@ceilidh 206 > stty -a I get: speed cluster baud; line = 0; intr = ^c; quit = ^u; erase = DEL; kill = ^x; eof = ^d; eol = ^` -parenb -parodd cs8 -cstopb -hupcl -cread -clocal -ignbrk -brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc -ixon -ixany -ixoff isig icanon -xcase echo echoe echok -echonl -noflsh opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3 Since I don't trust my eyeballs for a quick comparison scan, I save each to a different file, then run diff on them, and see no difference, so whatever the difference, it isn't the tty characteristics visible to the system. Anyone have any idea what is causing this? Thanks DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
kevin@cfctech.cfc.com (Kevin Darcy) (06/27/91)
In article <1991Jun26.160140.21483@colorado.edu> wouk@alumni.colorado.edu (Arthur Wouk) writes: [re: Jim Mercer's attempt to compile NetHack PL10 using gcc] >if you do get it to run, please make it available at osu. >-- >arthur wouk >internet: wouk@cs.colorado.edu Why not just put a version up which was compiled with the stock cc (if OSU doesn't already have one, that is)? Or would a partially-gcc-compiled binary be intrinsically better??? Just curious. ------------------------------------------------------------------------------ kevin@cfctech.cfc.com | Kevin Darcy, Unix Systems Administrator ...sharkey!cfctech!kevin | Technical Services (CFC) Voice: (313) 759-7140 | Chrysler Corporation Fax: (313) 758-8173 | 25999 Lawrence Ave, Center Line, MI 48015 ------------------------------------------------------------------------------
merce@iguana.uucp (Jim Mercer) (06/27/91)
In article <1991Jun26.041914.25466@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >i have compiled and run nethack3p9 on my 3b1. i have now also compiled nethack3p10. >i used gcc -traditional for all modules except monst.c which died in gcc >but was successful with the stock compiler. ditto >the problem i have is that when i use the 's' search function, it dies. the error message is Memory fault >i just shelled out and tried it again, and it didn't die on me. > >grrr. hmmm.... this is really wierd. if i log in, type "nethack<cr>NV@s" (run nethack, No, Valkirie, autopickup off, search), it dies with a Memory fault. if i log in, run rn, follow up an article, shell out from vi, then do the above it does not diee, but the search function does not seem to work. ie: >however, in my several attempts to find secret doors at the end of a couple >dead end tunnels, the search function now appears not to work at all. >(the 1st level screen showed 3 rooms, all on the left side of the screen, >with one of the tunnels leading off to the right.) hmmmm..... >anyways, i am currently building 3p10 in hopes that it might go away. it didn't >i am also recompiling everything with gcc -traditional as i might have >compiled a few with the stock compiler. rebuilt everything with gcc -traditional, except monst.o >i'll let you know what happens. not much changed. i'm gonna try another rebuild, this time leaving out the shared libraries. [ jeez i love nethack 8^) ] -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "If you've got the technology, you can party." Labatt's beer commercial ]
res@colnet.uucp (Rob Stampfli) (06/27/91)
> I have been being hit with this search bug, which is deadly if you >are an elf, since they automatically use the search by their very nature. I >have always been hit by it, till I just tried it by shelling out of trn, in >which it now works. Since it doesn't dump core, it makes it hard to >determine the source of the problem. The error message is: > > Memory fault ... > I hit the problem even if logged in via ethernet and rlogin, but if >I shell out, from trn, or from jove, I don't. I wonder why? Lets try >something! Often, when a program runs in one environment, but not in another, the problem is due to a bad reference on the stack. Depending on where the page breaks occur relative to the stack pointer, such a reference beyond the end of the stack pointer may either appear to work, or if it is truly beyond the last allocated page, cause a memory fault. The difference is that the programs have different environments pressed onto the stack when they are invoked. Try exporting a few garbage variables which have been set to long strings and see if this changes anything. If so, look for automatic arrays that are indexed beyond their defined size. -- Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh
wilber@alice.att.com (rew) (06/28/91)
In article <1991Jun26.220457.11464@yenta.alb.nm.us> dt@yenta.alb.nm.us (David B. Thomas) writes: >I've already gotten mine to work. I used stock everything ... >The trick to getting it to make was defining STUPID_CPP. > > little david I didn't have any problems. I used GNU C. I recommend to everyone that you use GNU cpp even with the stock C compiler. (A simple mod to the source prevents it from defining __STDC__.) You will never see "too many defines" again. While you're poking around in your favorite archive site, get berkeley yacc, too. You will never see "too many nonterminals" again. Bob Wilber
merce@iguana.uucp (Jim Mercer) (06/28/91)
In article <1991Jun27.002615.10481@cfctech.cfc.com> kevin@cfctech.cfc.com (Kevin Darcy) writes: >In article <1991Jun26.160140.21483@colorado.edu> wouk@alumni.colorado.edu (Arthur Wouk) writes: > >[re: Jim Mercer's attempt to compile NetHack PL10 using gcc] > >>if you do get it to run, please make it available at osu. i'll try, but right now i'm just killing time as my wife's labor pains are only 8 minutes apart. 8^) >Why not just put a version up which was compiled with the stock cc (if OSU >doesn't already have one, that is)? Or would a partially-gcc-compiled binary >be intrinsically better??? > >Just curious. i thought gcc would produce smaller and faster code. as i recall, the gcc binary was ~850K unstripped. the binary for the one built from stock is: -rwsr-xr-x 1 games games 708895 Jun 28 00:07 nethack oh well. i'll try and put it on osu sometime over the weekend. unless someone beats me to it. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "If you've got the technology, you can party." Labatt's beer commercial ]