OK, so I looked at a disassembly of my own code. I can already tell that the final link (the one that creates <TARGET>) is introducing the problem. Now, AFAIK this shouldn't happen due to -nostdlib, which implies -nostartfiles, as I *think* that's what introduces _start to the symbol table.
I looked at a disassembly of the code and ran a search for _start. It isn't called anywhere, so I don't see why it needs to reference _start. VxWorks also doesn't care about _start as it has it's own entry points.
I believe that something like the following would work as a temporary workaround:
Code:
extern "C" {
void _start() {
//output an error message?
}
}
As I believe it should never be called, I doubt this would be an issue. Then, for completeness' sake one should add "-L _start" to the objcopy command in powerpc-wrs-vxworks-munch. That way you don't pollute the kernel namespace with unnecessary symbols.
I also don't recalling this problem happening with old GCC. Therefore, I'm going to try a year old version of GCC and see if it still has this issue. If not, than it's a regression in the compiler. If I know this is the case, I can run a git bisect and determine exactly where this happened. I'm 90% sure it'll work with last march's gcc (as I seem to remember it working), so that's about 9 months. According to git there have been ~8800 commits in the past 9 months, and log2(8800) is about 13. So, thanks to the wonders of binary search, I can figure out what broke it. Then, that's just a bug report. I should be able to script it (I think [ `nm <TARGET> | grep _start | wc -l` -eq 1 ] will work as a testcase on the compilation).
I don't have that long though... GCC is in the last stage of development before release. This should count as a pretty serious regression though if it is what I think it is.
Sorry, thinking on forum. It helps me work it out...
Is that the ONLY unresolved symbol error you get?
EDIT: Nvm just checked the netconsole output. Thanks again for that. To be quite honest, this is better than I expected, considering how often these things can break.