Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Help on "C++ Programming with MacApp" book needed
Message-ID: <16028@hoptoad.uucp>
Date: 11 Mar 91 07:41:53 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> <1991Mar8.120743.2089@Informatik.TU-Muenchen.DE>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Electronics for Imaging, San Bruno CA
Lines: 41

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