breidenb@Informatik.TU-Muenchen.DE (Oliver Breidenbach) (03/04/91)
hi folks, being new to mac programming and interessted in MacApp, I decided to buy the book "C++ Programming with MacApp" by David Wilson, Larry Rosenstein and Dann Shafer. Together with the book comes a disk which has all the code on it. I worked my way through the book until chapter 9, where a simple MacApp program is described. All the previous programs in the book compiled without trouble. But all programs using MacApp libaries do not link. The linker gets me an error 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. I didn't change the code one single bit since copying it from disk to harddisk. I installed MacApp exactly as described in the book, except that the path is "Macintosh HD:Prog:MacApp 2.0" & "Macintosh HD:Prog:MPW" due to organisation of my data. I use MacApp 2.0 from CD and MPW 3.1 with C++ 3.1 under System 7.0b4. Any Ideas what could be wrong? Any help would be appreciated. Thanks in advance. Oliver. e-mail: Oliver.Breidenbach@Informatik.tu-muenchen.de or breidenb@tuminfo4.informatik.tu-muenchen.de
6600dtam@ucsbuxa.ucsb.edu (Marc "Tae-Kwon" Tamsky) (03/04/91)
I have the same problem with MacApp and C++... I get: ### 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. on every compile using MABuild. I'm using System 6.0.5 on a IIfx, MultiFinder, MPWShell3.2b8, MacApp2.0.1, C++ v3.1, C v3.1. I was about to send a message to apple, but I hope someone has a solution that they can share. Thanks, Marc Tamsky. 6600dtam@ucsbuxa.ucsb.edu -- = Marc Tamsky Under Capitalism, man expoits man. = = 6600dtam@ucsbuxa.ucsb.edu Under Communism, it's just the opposite. = = POB 12600, UCSB -J K Galbraith. = = Santa Barbara, CA 93107 (805)-562-5645 =
curreyr@argus.CS.ORST.EDU (Robert W. Currey) (03/05/91)
I was also having that problem getting MacApp and C++ to work using MABuild. In the Startup*MacApp file there is a variable defined called MABuildDefaults. This holds the various options you want as the default during the build process. For the linker there is an option -m that I guess tells the linker what the name of the main proedure of your appliucation (Apple can correct me if I wrong since I never did see any reference to this option in the help files). So setting '-m main' in the MABuildDefaults variable should fixx the problem. BTW, I'm using System 7.0b1, MPW 3.2b??, MPW C++ 3.1, MacApp 2.0. -Rob Currey curreyr@argus.math.cs.orst.edu
andrew@jhereg.osa.com (Andrew C. Esh) (03/05/91)
In article <9612@hub.ucsb.edu> 6600dtam@ucsbuxa.ucsb.edu (Marc "Tae-Kwon" Tamsky) writes: > >I have the same problem with MacApp and C++... I get: >### 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. > >on every compile using MABuild. > >I'm using System 6.0.5 on a IIfx, MultiFinder, MPWShell3.2b8, >MacApp2.0.1, C++ v3.1, C v3.1. > >I was about to send a message to apple, but I hope someone >has a solution that they can share. > >Thanks, >Marc Tamsky. >6600dtam@ucsbuxa.ucsb.edu > >-- >= Marc Tamsky Under Capitalism, man expoits man. = >= 6600dtam@ucsbuxa.ucsb.edu Under Communism, it's just the opposite. = >= POB 12600, UCSB -J K Galbraith. = >= Santa Barbara, CA 93107 (805)-562-5645 = I answered this same question about three weeks ago. Maybe we should put together a really solid solution to it, and include it in a FAQ file. The problem is your symbol table is getting overwritten. Go into the command line options for the C++ compiler and the linker and turn on all options that will dump informatin about symbol tables. You will see that the first few entries get corrupted, depending on the amount of code you are compiling. It's been so long since I solved this problem that I do not remember what the solution is, exactly. I think it has to do with increasing the size of the MPW memory, adding -mf to the linker options, increasing the size of the MPW stack (see Appendix I in the Vol 1 manual), or updating the compiler version. Someone with more recent experience should give more specific help with this. Please EMail me the solution, and I will save it for the next guy who finds this bug. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 So much System, (612) 525-0000 so little CPU time...
marc@Apple.COM (Mark Dawson) (03/05/91)
In article <9612@hub.ucsb.edu> 6600dtam@ucsbuxa.ucsb.edu (Marc "Tae-Kwon" Tamsky) writes: > >I have the same problem with MacApp and C++... I get: >### 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. > >on every compile using MABuild. > >I'm using System 6.0.5 on a IIfx, MultiFinder, MPWShell3.2b8, >MacApp2.0.1, C++ v3.1, C v3.1. > >I was about to send a message to apple, but I hope someone >has a solution that they can share. > I believe the problem is that you're linking with the wrong libraries...you should be linking with "{libraries}"runtime.o, NOT "{CLibraries}"CRuntime.o (as you would have in MPW 3.1). Hope this helps, Mark -- --------------------------------- Mark Dawson Service Diagnostic Engineering AppleLink: Dawson.M Apple says what it says; I say what I say. We're different ---------------------------------
andrew@jhereg.osa.com (Andrew C. Esh) (03/05/91)
In article <1991Mar04.172038.4060@lynx.CS.ORST.EDU> curreyr@argus.UUCP (Robert W. Currey) writes: > >I was also having that problem getting MacApp and C++ to work using >MABuild. In the Startup*MacApp file there is a variable defined called >MABuildDefaults. This holds the various options you want as the default >during the build process. For the linker there is an option -m that I >guess tells the linker what the name of the main proedure of your >appliucation (Apple can correct me if I wrong since I never did see any >reference to this option in the help files). So setting '-m main' in >the MABuildDefaults variable should fixx the problem. > >BTW, I'm using System 7.0b1, MPW 3.2b??, MPW C++ 3.1, MacApp 2.0. > >-Rob Currey curreyr@argus.math.cs.orst.edu Correct me if I'm wrong, but the linker defaults to "main". What is happening is the first few entries in the symbol table are getting overwritten, one of which is "main". Since the garbage that is sitting in the first entry's spot does not match the default "main" that the linker is looking for, it flags an error and stops. It is a problem with the C++ compiler. It trashes the entries, and the linker can't read it. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 So much System, (612) 525-0000 so little CPU time...
breidenb@Informatik.TU-Muenchen.DE (Oliver Breidenbach) (03/08/91)
In article <1991Mar5.155430.3246@jhereg.osa.com>, andrew@jhereg.osa.com (Andrew C. Esh) writes: |> |> Correct me if I'm wrong, but the linker defaults to "main". What is |> happening is the first few entries in the symbol table are getting |> overwritten, one of which is "main". Since the garbage that is sitting in |> the first entry's spot does not match the default "main" that the linker is |> looking for, it flags an error and stops. It is a problem with the C++ |> compiler. It trashes the entries, and the linker can't read it. |> -- Nevertheless setting the linker option -m main solved the problem as far as I'm concerned. The default seemed to be %__MAIN as the link-protokoll showed. And this is not defined anywhere. What is really upsetting is that a few codes compiled without trouble. I ran into that problem with all MacApp programs but not with all the regular C++ demo sources. So I wonder if it has to do with code-length and/or available RAM space. Since giving the compiler more space didn't solve that problem I consider it to be a combination of both. Oliver. --- Oliver Breidenbach, CSD, Technische Universitaet, Muenchen E-Mail: Oliver.Breidenbach@Informatik.TU-Muenchen.de
6600dtam@ucsbuxa.ucsb.edu (Marc "Tae-Kwon" Tamsky) (03/10/91)
>Nevertheless setting the linker option -m main solved the problem >as far as I'm concerned. The default seemed to be %__MAIN as the >link-protokoll showed. And this is not defined anywhere. >What is really upsetting is that a few codes compiled without trouble. >I ran into that problem with all MacApp programs but not with all the >regular C++ demo sources. So I wonder if it has to do with code-length >and/or available RAM space. Since giving the compiler more space >didn't solve that problem I consider it to be a combination of both. I would have to agree.... all I did was set the -m main in the link options, and everything was peachy. Do I have to worry that later on I'll run into this problem as my source and object files get bigger...? -- = Marc Tamsky Under Capitalism, man expoits man. = = 6600dtam@ucsbuxa.ucsb.edu Under Communism, it's just the opposite. = = POB 12600, UCSB -J K Galbraith. = = Santa Barbara, CA 93107 (805)-562-5645 =
tim@hoptoad.uucp (Tim Maroney) (03/11/91)
In article <1991Mar5.155430.3246@jhereg.osa.com>, andrew@jhereg.osa.com (Andrew C. Esh) writes: >|> Correct me if I'm wrong, but the linker defaults to "main". What is >|> happening is the first few entries in the symbol table are getting >|> overwritten, one of which is "main". Since the garbage that is sitting in >|> the first entry's spot does not match the default "main" that the linker is >|> looking for, it flags an error and stops. It is a problem with the C++ >|> compiler. It trashes the entries, and the linker can't read it. That is a reasonable explanation, except for one minor error. The linker defaults to call some MPW C run-time-system main entry point which is actually called by the Launch trap. This front-end routine to your "main" deals with (in C) converting the Mac argument format more or less to a convention using argc and argv, and some other stuff -- I have disassembled it recently. That's the "%__MAIN" that the linker wants to see. And it makes sense that a hash table might have bad error handling for pathological collision cases that fill up the symbol table, and respond by stepping on the initial entries. The fix of bumping the shell memory may work (since the linker tool runs in the shell heap). But there may be some linker table size argument or resource.... In article <1991Mar8.120743.2089@Informatik.TU-Muenchen.DE> breidenb@Informatik.TU-Muenchen.DE (Oliver Breidenbach) writes: >Nevertheless setting the linker option -m main solved the problem >as far as I'm concerned. The default seemed to be %__MAIN as the >link-protokoll showed. And this is not defined anywhere. Yes, you get this "%__MAIN" in the default linker libraries. Probably you are building right and hitting a linker bug. Your workaround makes sense because the run-time-system main entry point doesn't seem to do a whole lot of really important stuff. But don't try to get your application arguments from argc and argv if you keep working around the problem this way; use the Segment Loader routines. (MacApp ought to do this for you.) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I've been called an evil genius by cities of assholes... but I know who these people are! And they're on my list!" -- Robert Crumb
lsr@Apple.COM (Larry Rosenstein) (03/27/91)
In article <49879@apple.Apple.COM> marc@Apple.COM (Mark Dawson) writes: >In article <9612@hub.ucsb.edu> 6600dtam@ucsbuxa.ucsb.edu (Marc "Tae-Kwon" Tamsky) writes: >> >>I have the same problem with MacApp and C++... I get: >>### Link: Error: Main code (-m option) name not found. (Error 53) %__MAIN >> >>I'm using System 6.0.5 on a IIfx, MultiFinder, MPWShell3.2b8, >>MacApp2.0.1, C++ v3.1, C v3.1. > >I believe the problem is that you're linking with the wrong libraries...you >should be linking with "{libraries}"runtime.o, NOT "{CLibraries}"CRuntime.o >(as you would have in MPW 3.1). Assuming that Mark is right about the immediate cause, then the problem ight be that you are using a different version of MPW from the libraries. To account for library changes from MPW 3.1 to 3.2, the MacApp build tool checks the shell variable MPWVersion to see which version of the shell you are running. So running a 3.2bx shell with the 3.1 libraries might cause problems. You can try setting {MPWVersion} to 3.1 temporarily and see if that helps. THe real fix would be to get the 3.2 version of the C libraries. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 3-PK Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
lsr@Apple.COM (Larry Rosenstein) (03/27/91)
>So running a 3.2bx shell with the 3.1 libraries might cause >problems. You can try setting {MPWVersion} to 3.1 temporarily and see if I got the wrong variable. The MacApp build tool looks at the variable MAShellVersion. I also located the MPW 3.1 libraries, and building with them caused the linker error people have reported. Doing Set MAShellVersion 3.1 fixed the problem. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 3-PK Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
lsr@Apple.COM (Larry Rosenstein) (03/27/91)
> >I would have to agree.... all I did was set the -m main in the link >options, and everything was peachy. I don't think this is a good idea. There is special initialization code that has to run before your main, so main itself shouldn't be the program main entry point. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 3-PK Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
scotth@rocco.labs.tek.com (Scott Herzinger) (03/29/91)
Vis. MAShellVersion, I continued to have the no-main problem after I thought I'd installed correct (consistent) versions of everything. Eventually noticed that MAShellVersion wasn't being set correctly. In the 3.2bX releases that I've received, the MPW Version command, which is used to set MAShellVersion, produces strings of the form "MPW Shell 3.xxx". The 3.1 Version command produces strings like "MPW Shell Version 3.xxx". The script that sets MAShellVersion looked for "Version" and not finding it, set MAShellVersion to "". Just in case this is causing anyone else to pull their hair out. Scott Herzinger scotth@crl.labs.tek.com Computer Research Lab Tektronix, Inc. PO Box 500, MS 50-662 Beaverton, OR 97077