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