__main undefined symbol
Doug Evans
dje@transmeta.com
Sat Apr 1 00:00:00 GMT 2000
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
More information about the crossgcc
mailing list