• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 22 subscribers
  • Views 8238 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UNRESOLVED EXTERNAL SYMBOL, but why?

Nora

Hello,

I've got a small problem with the L166. In my project I have several C-files which use functions of osBoard.c. The functions are declared in osBoard.h.

osBoard.h:

void saveContext(void);
void restoreContext(void);
void saveStatus(void);
void restoreStatus(void);
CPU_BIT getStatus(void);
void setStatus(CPU_BIT statusregister);
void setIEN(INT8U ien);
INT8U getIEN(void);
void enableInterrupts(void);
void dissableInterrupts(void);
void setSP(CPU_BIT);
CPU_BIT  getSP(void);
void setInterruptLevel(INT8U ilvl);
INT8U getInterruptLevel(void);

I include the osBoard.h in every file which uses one of the functions (osSchedule, osSystem, ...). When Keil wants to link it throws a lot of errors and warnings.


linking...
*** ERROR L127: UNRESOLVED EXTERNAL SYMBOL
SYMBOL: getIEN
MODULE: .\obj\osSchedule.obj (OSSCHEDULE)

.... // same with all other functions

*** ERROR L128: REFERENCE MADE TO UNRESOLVED EXTERNAL
SYMBOL: getIEN
MODULE: .\obj\osSchedule.obj (OSSCHEDULE)

.... // same with all other functions

*** ERROR L127: UNRESOLVED EXTERNAL SYMBOL
SYMBOL: getIEN
MODULE: .\obj\osSystem.obj (OSSYSTEM)

.... // same with all other functions

*** ERROR L128: REFERENCE MADE TO UNRESOLVED EXTERNAL
SYMBOL: getIEN
MODULE: .\obj\osSystem.obj (OSSYSTEM)
ADDRESS: 1456H

.... // same with all other functions
Program Size: data=2932(near=2932) const=847(near=635) code=4842
Target not created


What did I do wrong because I use the same Source for another target and everything works there fine.

Thanks
Norbert

Parents
  • 0

    At close to 100% probability, you just forgot to also add osBoard.c source file (or an .obj made from it, or a .lib) to the project you're compiling.

    Remember: a .h file just makes a promise to the compiler that these functions exist, somewhere in the project's code base. It's up to you to keep that promise, by actually putting that code into the project, somehow.

Reply
  • 0

    At close to 100% probability, you just forgot to also add osBoard.c source file (or an .obj made from it, or a .lib) to the project you're compiling.

    Remember: a .h file just makes a promise to the compiler that these functions exist, somewhere in the project's code base. It's up to you to keep that promise, by actually putting that code into the project, somehow.

Children
  • 0 in reply to HansBernhard Broeker

    "a .h file just makes a promise to the compiler that these functions exist, somewhere in the project's code base"

    What an excellent way of putting it!

  • 0 in reply to Andy Neil

    Thanks for the reply, but in this project I've two targets. When I compile the project for the C167 everything is just fine. The linker just nags with the XC167 target.

  • 0 in reply to Nora

    I found the problem. The problem was that in "osBoard.c" I had a

     #ifdef C167 || XC167
    which doesn't work.

    Thanks for all replies.

  • 0 in reply to Nora

    Ever since 1989 (ANSI C), the preferred syntax has been

    #if defined(SYMBOL)

    rather than the K&R style

    #ifdef SYMBOL

    In this case,

    #if defined(A) || defined(B)

    would have worked just fine. This case of a compound expression was in fact one of the reasons motivating the change in syntax.

    It's impossible to drop support for #ifdef due to the large body of existing code, of course. But it seems that the new style has been slow to catch on, at best, and lots of new code still gets created with #ifdef rather than #if defined(), which just exacerbates the problem.