wes@arco.com (Wesley Monroe) (06/07/91)
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? Thanx, wes wes@arco.com
ml27192@uxa.cso.uiuc.edu (Mark Lanett) (06/07/91)
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. >Thanx, >wes >wes@arco.com -- //----------------------------------------------------------------------------- Mark Lanett mlanett@uiuc.edu Software Tools Group, NCSA
ksand@apple.com (Kent Sandvik) (06/09/91)
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
ml27192@uxa.cso.uiuc.edu (Mark Lanett) (06/09/91)
ksand@apple.com (Kent Sandvik) writes: >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" Guys, I keep saying this: MacApp 2.0.0 from the CD ROM does not have this option and neither the MABuildTool nor MacApp source make use of it. Hence the workarounds I described earlier. Re: Fragmentation This shouldn't apply if you use the 3.1 libraries, should it? -- //----------------------------------------------------------------------------- Mark Lanett mlanett@uiuc.edu Software Tools Group, NCSA