• State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 22 subscribers
  • Views 7733 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

BL51: '*** WARNING L1: UNRESOLVED EXTERNAL SYMBOL'

Gary Lynch

I am designing an application to run on the Si Labs
C8051F046 MCU with uVision 3. Yesterday I created a new
project, but forgot to include one of the source modules.
This produced a line during the link in the Output Window:

  *** WARNING L1: UNRESOLVED EXTERNAL SYMBOL

I missed it, as this program generates many similar warnings:
  *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS

(in that tiny, little output window) which I must ignore.
Because L1 is only a warning; BL51 completed the build and
gave me a load module, which I attempted to debug. (It came
fairly close to working). I wasted an hour tracking the
cause back to this source.

I can't think of any scenario where I would want the build
to continue with missing source modules, yet I can find no
tool that would allow me to make L1 an error instead of a
warning. As best I can tell, this topic has never appeared
in the knowledge base or on this forum.

Does anybody have a differing opinion? A workaround?

Advance thanks for any insight.
============================================================
Gary Lynch            |     To send mail, change no$pam in
lynchg@no$pam.com     |     my domain name to stacoenergy

Parents
  • 0 in reply to Gary Lynch

    This interacts with an idiosyncracy of BL51
    to make it jump to the (erroneous) conclusion my
    functions are calling themselves recursively.

    The linker is not making any erroneus conclusions. It tries to construct a calling tree for your functions, but fails as soon as function pointers come into play since the Linker has absolutely no idea what values the function pointers will have during run-time. It therefore makes the right decision by not considering those functions for overlaying.

    Don't blame the linker for perfectly expected behavior.

Reply
  • 0 in reply to Gary Lynch

    This interacts with an idiosyncracy of BL51
    to make it jump to the (erroneous) conclusion my
    functions are calling themselves recursively.

    The linker is not making any erroneus conclusions. It tries to construct a calling tree for your functions, but fails as soon as function pointers come into play since the Linker has absolutely no idea what values the function pointers will have during run-time. It therefore makes the right decision by not considering those functions for overlaying.

    Don't blame the linker for perfectly expected behavior.

Children
No data