Hi, >>> But now with the startup code living in the C/runtime library the >>> whole thing doesn't get started if main() lives in a library - at >>> least that's how things look to me. >> >> I don't know much about Contiki, but there must be something, the application >> must do to make use of it. How about adding a >> >> .forceimport _main >> >> somewhere in a library module that *must* be used by an application? > > Thanks for the hint. However to me this looks like a workaround (or > even a hack) but not like a true solution. > > From my perspective it seems reasonable to presume that the linker > together with the C/runtime library does "somehow make sure" that > main() is referred. > > I understand that the linker fore sure isn't limited to C programs so > it doesn't make sense to hard-code such a reference but what about > i.e. extending the linker config syntax/functionality to allow > something analog to .forceimport (being kind of the "opposite" of > SYMBOL {}, maybe called IMPORT {}). The builtin linker configs could > then use that functionality for the symbol _main. No feedback at all on my posting above ? Just imagine forgetting or misspelling main(). Wouldn't you expect the linker (called with -t <target>) to complain about not being able to resolve the symbol '_main' ? The current snapshot issues instead rather cryptic messages about some missing but obligatory segments because it doesn't link in the startup code. Best, Oliver ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sun Aug 23 10:01:28 2009
This archive was generated by hypermail 2.1.8 : 2009-08-23 10:01:29 CEST