Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!sdd.hp.com!ucsd!ucbvax!agate!shelby!msi.umn.edu!cs.umn.edu!ux.acs!vx.acs.umn.edu!dhoyt
From: dhoyt@vx.acs.umn.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problems with MPW Link & MacApp (and more problems)
Message-ID: <2596@ux.acs.umn.edu>
Date: 30 Oct 90 15:44:57 GMT
Sender: news@ux.acs.umn.edu
Organization: University of Minnesota, Academic Computing Services
Lines: 22

In article <10909@pt.cs.cmu.edu>, mkb@rover.ri.cmu.edu (Mike Blackwell) writes...
>### Link: Error: Main code (-m option) name not found. (Error 53) %__MAIN
>### Link: Error: No Main code module or entry point. (Error 38) 
>### Link: Errors prevented normal completion.

  I find this to happen whenever I use -AutoBuild.  When I want to recompile
an new system, I use -AutoBuild to compile all of the MacApp code, then
use -NoAutoBuild to compile my code.  This seems to work most of the time.

  As I side note, I have been having illegal instruction errors from a
subroutine called by cplusinit (or whatever) causing the program to terminate
before main() is ever called.  I have a const char[], but no initialized global
statics, no stream i/o, really nothing that I can see that would make the
initializer call anything differently for this program than other (working)
applications.  I am using 2.0b9 of MacApp and the beta version of c++.

  When I do get the program to call main() (I haven't figured out how I manage
this yet) it will blow up from MacApp (after TApp->run()) while trying to
unload all segments (including Main).  MacApp then kindly warns me that
unloading a segment that I'll return to is a Bad Idea.  Clues?

david | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet