Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mephisto!mcnc!rti!sas!walker From: walker@sas.UUCP (Doug Walker) Newsgroups: comp.sys.amiga.tech Subject: Re: Lattice 5.04 problem Message-ID: <1346@sas.UUCP> Date: 27 Nov 89 13:29:54 GMT References: <1989Nov22.022406.9843@athena.mit.edu> <128264@sun.Eng.Sun.COM> <1989Nov23.032623.13429@agate.berkeley.edu> Reply-To: walker@sas.UUCP (Doug Walker) Organization: SAS Institute Inc, Cary NC Lines: 34 In article <1989Nov23.032623.13429@agate.berkeley.edu> mwm@eris.berkeley.edu (Mike (With friends like these, who needs hallucinations) Meyer) writes: >In article <128264@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: > (Rich Carreiro) writes: ><>OK, it compiles fine, but when it begins to link I get: ><>Undefined Symbol First Referenced ><>@main LIB:lcr.lib The problem here is that the startup code (c.o or whatever) refers to the routine __main in the libraries, which in turn refers to your main routine. Since you are linking with the registerized library, it calls main as a The at sign before the name indicates the routine is being called registerized; the underbar indicates it is being called stack-based. This prevents a possibly catastrophic mix of registerized and stack-based calls, and instead results in a link error (like this one). The fix is one of two things: 1. BEST - stick in a prototype for main. This will cause __main to call it registerized and everything will work fine. 2. NOT SO GOOD - link with lc.lib BEFORE lcr.lib. This will resolve the symbol __main to the NON-registerized version. It will also resolve any other library routines that you didn't include the prototype for, which hopefully is none of them. This method has the disadvantage of hiding non-registerized calls that you may not have intended to be non-registerized. ***** *|_o_o|\\ Doug Walker, Software Distiller *|. o.| || | o |// "It is well to remember that evil is a pretty bad thing." ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker