Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!ksand@apple.com
From: ksand@apple.com (Kent Sandvik)
Newsgroups: comp.sys.mac.programmer
Subject: Re: FAQ MPW C++ "main() missing question"
Message-ID: <13970@goofy.Apple.COM>
Date: 8 Jun 91 17:33:10 GMT
References: <1991Jun6.224326.10385@Arco.COM> <1991Jun7.072212.5314@ux1.cso.uiuc.edu>
Sender: usenet@Apple.COM
Organization: Apple, Platforms&Tools Group, DTS
Lines: 134

In article <1991Jun7.072212.5314@ux1.cso.uiuc.edu>, ml27192@uxa.cso.uiuc.edu (Mark Lanett) writes:
> 
> wes@arco.com (Wesley Monroe) writes:
> 
> >I am having a problem I know I have seen the answer to 
> >on the net at one time or the other.
> 
> >When i go to link an C++ app, I get the following message:
> 
> >### 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.
> 
> >What gives?
> 
> What gives is 1) you're using MacApp 2.0.0 and 2) System 7 and MPW 3.2
> and therefore 3) macApp is trying to link with the 3.2 libraries even though
> it's not compatible with them (though the Apple guys who are running 2.0.1
> think it is).
> Change the IF statement in MABuildTool.p on line 1428 to read "if false"
> and recompile (under system 6, of course) to get it to use the 3.1 libraries.

Well, I've used MPW 3.2 with 2.0.1 and 2.0, and as long as you uncomment this
line in {MacApp}Startup, it's OK:

# for compatibility with MPW 3.1 ( the currently released product )
# for MPW 3.2 or later remove or comment out the following line
#SET MABuildDefaults "{MABuildDefaults} -d qMPW31=TRUE"

It is also maybe time and place to repost an important message sent on
MacApp.Tech$ some time ago about a known refragmentation problem with MacApp 2.0(.1)
and MPW 3.2 final. So here it is (n.b, it's about MPW 3.2 final which is not shipping yet):

---------------------------------------------
%%% News Flash from MacApp.Test %%%
 
VERY IMPORTANT!!
 
MacApp versions 3.0 a2 or earlier ( including MacApp 2.01 and prior ) have a
bug when compiled with MPW 3.2.  Due to some re-segmentation in the MPW
Libraries, if you use a version of MacApp that has been compiled with 3.2 you
may notice some serious heap fragmentation in your MacApp applications.  We
noticed this bug when calling SetHandleSize (it promptly failed while
attempting to grow the handle).  The primary solution to the problem is to use
MPW 3.1 when compiling MacApp version 3.0 a2 or earlier.
 
If you REALLY need or want to use MPW 3.2, you must make the following
modifications to your Basic Definitions (this workaround has not been
thoroughly tested so... USE AT YOUR OWN RISK!):
 
 SegmentMappings = 6
 #---- insert here
   -sn PASLIB=Main 6
   -sn STDCLIB=Main 6
 #---- end of insertion
 
 modify the following declaration in your MacApp.r ( in 3.0 this declaration
will be found in Memory.r )
 
resource 'seg!' (kBaseMacApp,
#if qNames
   "BaseMacApp",
#endif
   purgeable) {
   {   "Main";
   "MAMain";
   "GMain";
   "GRes";
   "GRes2";
   "ARes";
   "BBRes";
   "BBRes2";
   "%_MethTables";
   "GError";
 #---- insert here
   "INTENV";
   "SADEV";
   "INTENV";
   "STDIO";
   "PASLIB";
   "STDIO";
   "STDCLIB";
 #---- end of insertion
 
 
resource 'res!' (kBaseMacApp,
#if qNames
   "BaseMacApp",
#endif
   purgeable) {
   {   "Main";
   "MAMain";
   "GMain";
   "GRes";
   "GRes2";
   "ARes";
   "BBRes";
   "BBRes2";
   "%_MethTables";
   "GError";
 #---- insert here
   "INTENV";
   "SADEV";
   "INTENV";
   "STDIO";
   "PASLIB";
   "STDIO";
   "STDCLIB";
 #---- end of insertion
 
 
 
One other possible solution would be to mark code resources produced by the
libraries that were once in main as locked. Then, these segments would be
loaded into memory and placed with the main segment, avoiding fragmentation
problems. This can be done by modifying the user variable OtherLinkOptions in
the Basic definitions file:
 
 OtherLinkOptions = 6
-raPASLIB=resLocked6
-raSTDCLIB=resLocked
 
 
It would still be necessary to modify the SEG! resource as described above.
Again, remember these fixes haven't been thoroughly tested, so use them at your
own risk.
 
Love and Kisses,
Zimbula
 
------------
Regards,

Kent Sandvik