Hi
I ran into a odd problem yesterday when I add a code file to control the GPIO for a Cortex M3. All of the routines that were being called from the main code (4 of them) were called out by the linker to be undefined symbols. ??? The .c file compiled with no errors.
I did some experiments to see what the issue might be. I thought maybe the calling signature was wrong and it could not match it up so I cut and pasted just the subroutine definition of one of the subroutines and put it into the top of the only file that called that particular one and just made it a do nothing loop and the linker did resolve the subroutines name/symbol!!
So it is has nothing to do with how the subroutines are called or defined. I did another experiment to see if it had anything to do with the physical number of files being linked. I combined the new GPIO.c file with a existing file and removed the GPIO.c from the link list. I relinked and all of the subroutines names/symbols were resolved BUT a another assembly language name showed up as unresolved. Gees. Its definitely there in a totally different .s file so I don't know why started it will not resolve all of the sudden.
I tried combining more and more files to reduce the number of physical files but nothing seemed to help make this new unresolved system that did not show up before, go away.
So now I don't know what to do. The only thing that makes sense (cause and effect) is a limit on the number of files that the linker can accept. Maybe beyond that there is a internal limit on the number of routines or something that is causing this .s routine to be declared undefined.
Has anyone ever had a problem like this before?
Thanks
Well if you're mixing in C++ (.cpp) files then you're going to need to be acutely aware of the name mangling done for type checking purposes, and ensure that when you call C routines you make the compiler explicitly aware of this. Otherwise, yes you'll see the linker failing.
extern "C" void foo(int); // of whatever
I'm not aware the linker has a file limit issue, although I haven't validated such, most would take a response file where command line constraints exist, it's not like we're using DOS tools in 1984.