We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Yes, I know about all the neophyte mistakes that cause the Linker to fail to find a symbol and result in L6218E error messages. This is not one of those cases. The error message (with non-essential parts x'd out) is:
.\_build\xxxxx_app.axf: Error: L6218E: Undefined symbol app_uart_init (referred from main.o).
So it's having trouble finding app_uart_init. But that symbol is indeed available, from a header file that is included in main.c, along with a bunch of other symbols that are found. This symbol is a function name, with a fairly complex signature. My assumption is that the symbol matches just fine, but the linker is finding a mismatch between the declared signature and how the function is invoked in my code. But the L6218E error message is singularly unhelpful in this regard. Is there any way to get more info (e.g., in the Linker Map file) about what it thinks the specific problem is, e.g., which argument type fails to match? I even went through the trouble of explicitly casting each of the actual function call arguments to the type specified in the function definition. Compiler was perfectly happy; didn't even issue a warning, but the Linker still failed. Sigh... Is there any way to diagnose this without going through all possible permutations of argument casting, etc?
TIA,
Mike
Thanks for the quick reply:
Signature? Casting parameters? Are you programming in C++? Because C doesn't use any name mangling for parameter types.
I'm programming in C, not C++. Looks like I'm presuming too much from C. Had presumed that the compiler was saving function argument and return type info (no name mangling involved), and that the linker was checking it.
By the way - why did you not specify any architecture?...
Because your web form does not give me a useful choice :-) I'm using an ARM Cortex-M0 (in a Nordic nR51822, BTW) which isn't listed in the available choices. Guess I could have selected "ARM-7..."
The header files are there for the compiler. They are irrelevant for the linker. When it gets time to link, you need that symbol available in an object file or a library that you have instructed the linker to care about.
Yes, I know. But you do make a good point. I'll go back and make sure the linker has access to the correct object file.
Whoops! The linker did not have access to the right object file. My error. I'm in the middle of switching between two versions of the library and the compiler had access to the correct file, but not the linker.
Guess I keep forgetting how primitive C is and was overthinking the problem. And it's interesting that the C spec doesn't have much to say about the linking process. (At least my copy of Harrison & Steele doesn't)
Thanks for setting me right. Consider this thread closed.