Xref: utzoo rec.games.hack:1820 comp.sources.bugs:579
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!cbosgd!mandrill!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: rec.games.hack,comp.sources.bugs
Subject: Re: NetHack gives memory fault on 3B2 (was Re: NetHack Woes)
Message-ID: <6506@ncoast.UUCP>
Date: 16 Dec 87 02:58:29 GMT
References: <2394@killer.UUCP> <33@musky2.EDU>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: rec.games.hack
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 21

As quoted from <33@musky2.EDU> by terrell@musky2.EDU (Roger Terrell):
+---------------
| In the Makefile (Makefile.att), the files were linked using 'ld' directly
| rather than through the default pass the C compiler makes.  Since 'ld' does
| not search the C libraries when called directly, this stage bombed out.
| To fix this, I just passed all of the .o files to the C compiler myself
| and it linked without problem.  Did they need to be linked with 'ld' directly
| for some reason?
+---------------

The "Makefile.att" was the AT&T equivalent of "All the world's a VAX"; as it
turned out, the "AT&T" Makefile was for the 3B1 ONLY.  The load step invokes
the 3B1's shared library; this CANNOT be done via the C compiler on the 3B1.
Basically, "/lib/crt0s.o" is the shared-library startup file and
"/lib/shlib.ifile" defines addresses within the shared library; think of it
as the equivalent of -lc and -ltermlib (actually, it's -ltam, but works out
to approximately the same thing).
-- 
Brandon S. Allbery		      necntc!ncoast!allbery@harvard.harvard.edu
 {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
			Moderator of comp.sources.misc