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


Doug Evans wrote:

>  > Actually, there is a compelling reason to continue doing things the way they are---
>  > given Linux's rapid uptake by the embedded world, it's only a matter of time before a
>  > strictly embedded target (i.e. sh) becomes a linux-hosted target.  Having to go back
>  > and add a call to _main() in GCC would only slow things down, and create additional
>  > work.
>
> Why would one be in a position of having to "add a call to _main() ..."?

Geez, as much as I write, you would think that I could actually put down something
intelligible once in a while...  :^)

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.

> I think we're looking at things from slightly different angles.
>
> To very superficially touch on what I'm refering to:
>
> - how many recognize that while the [relatively] new -specs argument solves a problem that
> needs to be solved, it's not quite the right way to do it [innards of gcc opened up to
> user, especially since the syntax of specs files has its own problems]

I have no clue about -specs.  In fact, of the gadzillions of switches gcc supports, I'm
intimately familiar with about ten of them, maybe.

> - do we really need -nostdlib, -nostartfiles, -nodefaultlibs?

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.

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

b.g.

--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems
To teach is to learn.




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