This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: __main undefined symbol


William Gatliff writes:
 > What I meant was that, according to Jeff, gcc brute-force calls _main() from main() because:
 > 
 >    * it needs to be called somewhere, and
 >    * on most desktop hosts (i.e. Linux), we can't assume that it gets called anywhere else.
 > 
 > If someone ports gcc to a new architecture, they should (for now) still leave the
 > _main() call intact, even though it's kinda annoying, because it's only a matter of time
 > before Linux will run on that target, at which point the _main() call *has* to be there.
 > 
 > In other words, for as long as gcc has to generate a call to _main() itself, I want it to do
 > it consistently across all supported platforms, because it saves the gcc maintainers some
 > work in the long run.  For that, a small wart on my code is a fair trade.

gcc generates calls to __main for only a subset of the supported
targets.  For example you won't find calls to __main in the m32r-elf
port. :-)  Neither does the i386-linux port generate calls to __main.
I could go back and check, but I'm guessing that the i386-linuxaout
port *does* generate calls to __main, but i386-linuxaout is deprecated
if not ancient history.

 > There is a better way out there, I'm sure, and changing things would definitely remove more
 > of gcc "black box" behavior in this department.  For now, however, I'm content because,
 > despite all the warts, it still works pretty well.

Sure.  And cleaning it up will be a lot of work.
GCC could, however, decide and document a direction if not a
solution and have ports slowly fixed over time and require new ports
to not do deprecated things.

 > > These issues are orthogonal to anything embedded-linux related.
 > 
 > Now that I understand your position a bit better, I agree.  However, how many projects depend
 > on things working the way they are?  If in a future release of gcc we tell every other
 > project that they must add explicit commands to link runtime library files et al, for
 > example, we'll break a lot of shit, right?  That's why gcc will probably always need to make
 > special concessions for desktop users...

Certainly we can't break things for desktop and embedded users.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]