Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!ira.uka.de!fauern!NewsServ!breidenb
From: breidenb@Informatik.TU-Muenchen.DE (Oliver Breidenbach)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Help on "C++ Programming with MacApp" book needed
Message-ID: <1991Mar8.120743.2089@Informatik.TU-Muenchen.DE>
Date: 8 Mar 91 12:07:43 GMT
References: <1991Mar3.161029.16931@Informatik.TU-Muenchen.DE> <9612@hub.ucsb.edu> <1991Mar04.172038.4060@lynx.CS.ORST.EDU> <1991Mar5.155430.3246@jhereg.osa.com>
Sender: news@Informatik.TU-Muenchen.DE
Organization: Technische Universitaet Muenchen, Germany
Lines: 25
Originator: breidenb@sunwartung1.informatik.tu-muenchen.de


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