Re: __main undefined symbol

[Scott A Sumner <sasumner at juno dot com>]

Bill/Everyone:

I tried the _main() wart trick on my embedded system, but got a linker
error so had to back it out.  I've often wondered what was going on with
what appeared to be constructors being called when my startup code calls
main(), and thanks to today's discussions I now know.  I can't get rid of
it on my system, but at least I know about it...  And I've got to agree
with those folks working on embedded systems who don't want a compiler
making assumptions about what they want.  Frustrating!

Time to vent:  On a related (startup code) and again frustrating note, my
implementation of gcc requires me to have a crt0.o file.  This is not so
bad in itself (although I can't rename it or change its extension), but
what bugs me to no end is that it has to be in a subdirectory in the
compiler's directory tree.  We like to keep our tools on a readonly
network drive, so you can imagine the difficulties that arise with crt0.o
when it needs to change.  Is there a way around this?  If not, why would
the designers of my gcc implementation do what seems a dumb thing?  Or am
I wrong in thinking it is a dumb thing to segregate crt0.o from the rest
of the object modules?

Scott


On Tue, 08 Feb 2000 13:48:40 -0600 William Gatliff <gatliff@haulpak.com>
writes:
> Doug:
> 
> 
> > Startup code is one of the rats nests in GCC.
> 
> Actually, not really, at least in my opinion.  The only thing I've 
> seen that I
> don't like is that GCC adds a call to _main when it compiles main, 
> which is
> totally inconsistent to me.
> 
> I would rather see the _main called in crt0, because my application 
> may not even
> *have* a main--- I heavily modify crt0 to do lots of wierd things 
> not normally
> done in a desktop environment, and if GCC makes certain assumptions 
> (like calling
> _main on its terms), then I lose control that I may need.
> 
> > You have to remember that GCC supports M different cpus and 
> several file
> > formats, ALL of which have their own way of doing things and ALL 
> of which GCC
> > has to do correctly for their respective environments.
> 
> Which is why ELF (from what little I know about it) will save us 
> all--- except in
> my world, where SREC and other binary-oriented formats are king.
> 
> This is also why GCC shouldn't even *try* to do startup-specific 
> stuff like
> calling _main.  That's crt0's job.
> 
> > libgcc.a contains most of the runtime support that GCC compiled 
> programs needs.
> > [snip]  Another thing it contains [for targets that need it] is 
> __main, and its
> > job is to run the constructors for global objects.
> 
> This seems like the right place to put _main's implementation, but I 
> still don't
> like the idea that, when GCC sees that it's compiling main, it 
> inserts a call to
> _main in it.  *That's* a wart, in my book.
> 
> b.g.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com