Re: __main undefined symbol

[Doug Evans <dje at transmeta dot com>]

William Gatliff writes:
 > > 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.

Generally though, you would compile to ELF, and then at the end
use either the linker or objcopy (or whatever) to create the
SREC/binary files.  ELF and SREC/binary are complementary, whereas
a.out and coff are throwbacks to a more primitive era.

 > 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.

Jeff touched on why things are the way they are.
In the hosted (non-embedded) environment, we have no control over
crt0.  In the embedded environment we usually do have control -
however, GCC often does just follows what the hosted platforms do/did
when there is no compelling reason (at the time of the port) to do
something different.

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