srp@ethz.UUCP (Scott Presnell) (08/04/87)
Hello, I've got a problem compiling and linking nethack under MSC 4.0 on a stock AT (all hack options defined). Take a gander... >Microsoft (R) Overlay Linker Version 3.51 >Copyright (C) Microsoft Corp 1983, 1984, 1985, 1986. All rights reserved. > >Object Modules [.OBJ]: DECL.OBJ APPLY.OBJ BONES.OBJ CMD.OBJ DO.OBJ + >Object Modules [.OBJ]: DO_NAME.OBJ DO_WEAR.OBJ DOG.OBJ DOGMOVE.OBJ + >Object Modules [.OBJ]: EAT.OBJ END.OBJ ENGRAVE.OBJ FIGHT.OBJ + >Object Modules [.OBJ]: FOUNTAIN.OBJ HACK.OBJ INVENT.OBJ LEV.OBJ MAIN.OBJ + >Object Modules [.OBJ]: MAKEMON.OBJ MHITU.OBJ MKLEV.OBJ MKMAZE.OBJ + >Object Modules [.OBJ]: MKOBJ.OBJ MKSHOP.OBJ MON.OBJ MONMOVE.OBJ + >Object Modules [.OBJ]: MONST.OBJ O_INIT.OBJ OBJNAM.OBJ OPTIONS.OBJ + >Object Modules [.OBJ]: PAGER.OBJ POLYSELF.OBJ POTION.OBJ PRAY.OBJ + >Object Modules [.OBJ]: PRI.OBJ PRISYM.OBJ READ.OBJ RIP.OBJ RUMORS.OBJ + >Object Modules [.OBJ]: SAVE.OBJ SEARCH.OBJ SHK.OBJ SHKNAM.OBJ SIT.OBJ + >Object Modules [.OBJ]: SPELL.OBJ STEAL.OBJ TERMCAP.OBJ TIMEOUT.OBJ + >Object Modules [.OBJ]: TOPL.OBJ TOPTEN.OBJ TRACK.OBJ TRAP.OBJ TTY.OBJ + >Object Modules [.OBJ]: UNIX.OBJ U_INIT.OBJ VAULT.OBJ WIELD.OBJ + >Object Modules [.OBJ]: WIZARD.OBJ WORM.OBJ WORN.OBJ WRITE.OBJ ZAP.OBJ + >Object Modules [.OBJ]: VERSION.OBJ RND.OBJ ALLOC.OBJ MSDOS.OBJ >Run File [DECL.EXE]: HACK.EXE /NOIG /STACK:6000; >Segment size exceeds 64K >Input File: MSDOS.OBJ(msdos.c) pos: 9A Record type: 98 >*** Error code 149 I'm not sure I understand the meaning of that error in the context of a large model program. I am certain that all modules were compiled with the large model option switch. I'm bummed :-(. Anyone got any clues? Also there is apparently some bug in makedefs which trashes the first two lines in onames.h so that I must add back in the lines defining the AMULET_OF_YENDOR and a STRANGE_OBJECT. Other than a few small other errors the rest compiles ok, it's just the linking problem. Regards, Scott Presnell Organic Chemistry Swiss Federal Institute of Technology (ETH-Zentrum) CH-8092 Zurich, Switzerland. uucp:seismo!mcvax!cernvax!ethz!srp (srp@ethz.uucp); bitnet:Benner@CZHETH5A
dkp@hadron.UUCP (David K. Purks) (08/07/87)
In article <165@bernina.UUCP> srp@ethz.UUCP (Scott Presnell) writes: >Hello, > I've got a problem compiling and linking nethack under MSC 4.0 on >a stock AT (all hack options defined). Take a gander... > . . . >>Run File [DECL.EXE]: HACK.EXE /NOIG /STACK:6000; >>Segment size exceeds 64K >>Input File: MSDOS.OBJ(msdos.c) pos: 9A Record type: 98 >>*** Error code 149 > >I'm not sure I understand the meaning of that error in the context of a >large model program. I am certain that all modules were compiled with the >large model option switch. I'm bummed :-(. Anyone got any clues? > >Also there is apparently some bug in makedefs which trashes the first two >lines in onames.h so that I must add back in the lines defining the >AMULET_OF_YENDOR and a STRANGE_OBJECT. > First, the problem with makedefs appears to be a very strange problem with Microsoft version 4.0. When you do an freopen() using "w+" for stdout, the first two lines of output get thrown away. The easiest portable way to fix it is to: #ifdef MSDOS #define FILEMODE "w" #else #define FILEMODE "w+" #endif and then to globally change the "w+" to be FILEMODE. There is another problem with makedefs in this environment. The rename() calls fail because the old file name still exists. For each rename() call do: #ifdef MSDOS remove(oldfile); #endif rename(newfile,oldfile); Scott pointed out something that I missed...that the problem with the first two lines was what was causing some of my symbols to disappear (namely AMULET_OF_YENDOR). To solve the problem of the segment being too big, recompile all the modules with the -Gt switch. I've set it to 100 (-Gt100) and it compiles and links correctly (other than the fact that it says _dothrow, _getcomspec, _setty, and _uptodate are undefined...I haven't had a chance to look into these yet). I had serious problems with the makefile & make.ini as distributed (I'm using NDMAKE version 3.8, not the one supplied with MSC v4.0). Let's hope we can get this compiled and running soon. If you do, be sure to keep Mike Stephenson (seismo!mnetor!genat!mike) posted of the mods you had to make so we can all have the most up to date version. Dave Purks
greg@gryphon.CTS.COM (Greg Laskin) (08/08/87)
In article <165@bernina.UUCP> srp@ethz.UUCP (Scott Presnell) writes: >>Run File [DECL.EXE]: HACK.EXE /NOIG /STACK:6000; >>Segment size exceeds 64K >>Input File: MSDOS.OBJ(msdos.c) pos: 9A Record type: 98 >>*** Error code 149 > >I'm not sure I understand the meaning of that error in the context of a >large model program. I am certain that all modules were compiled with the >large model option switch. I'm bummed :-(. Anyone got any clues? > The compiler places all initialized static storage in the default (_DATA) data segment. All quoted ("string") strings are initialized static storage so the end up in _DATA. _DATA is overflowing. The author attempted, in the Xenix version, to give different data segment names to the various modules by using -ND (/ND). Unfortunately this won't work because the compiler sets the DS register whenever a module so compiled is entered. The library was not thusly compiled so static references made within library routines called from modules compiled with explicit data segment names are to the wrong data segment since the library was not compiled with explicitly named data segments. You can use modules with explicitly named data segments if those modules contain only data declarations or make no library calls. A small inconvenience there :-). There may also be some problems if the amount of static data in a module with an explicit data segment name exceeds 32K. The solution involves replacing all the quoted strings with pointers to static character arrays residing in modules with explicit data segment names. In Xenix you can almost get there with xstr except that xstr chokes when the string file exceeds 32K and the SCO Xenix version has some other amusing deficiencies, at least in V2.1.3, but with a bit more hacking, I should have it working under Xenix. I don't know of an xstr equivalent for DOS, however. -- Greg Laskin "When everybody's talking and nobody's listening, how can we decide?" INTERNET: greg@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4}!crash!gryphon!greg UUCP: {philabs, scgvaxd}!cadovax!gryphon!greg
ignatz@aicchi.UUCP (Ihnat) (08/08/87)
You're right, that in large model you can have more than 64K of, say, static; but you can't have more than 64K (1 segment) of static per source file. Check your total allocation/file... -- Dave Ihnat Analysts International Corporation (312) 882-4673 ihnp4!aicchi!ignatz || ihnp4!homebru!ignatz