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:
 > Doug:
 > 
 > > 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.
 > 
 > 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() ..."?

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]

- do we really need -nostdlib, -nostartfiles, -nodefaultlibs?
  [all hacks that solve only part of a general problem, the solution
  of which would also encompass the -specs wart]

These issues are orthogonal to anything embedded-linux related.

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