• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 29 subscribers
  • Views 273 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/ARM-CGT: --scan_library throws warnings for weak functions

user6135372
Intellectual 720 points
Part Number: ARM-CGT
Other Parts Discussed in Thread: HALCOGEN

Tool/software: TI C/C++ Compiler

Linking with --scan_libraries throws errors when a weak function has an additional non-weak implementation.

error #10252-D: Symbol "canMessageNotification" (pulled from "src\can.a<can.c.1.obj>") defined in 2 places:
   src\can.a<can.c.1.obj>
   src\hal\hal.a<HL_notification.c.1.obj>

How do I (if possible locally) suppress this warning for specific functions?

  • 0
    TI__Guru**** 232670 points

    I am not certain about some details of your case.  I presume the function canMessageNotification is weak in one library and strong in the other.  Even so, which implementation is used by the linker is not affected by the weak or strong attribute.

    To understand how that works, please search the TI ARM assembly tools manual for the sub-chapter titled Exhaustively Read and Search Libraries.  Because this process is very detailed, the linker also provides the option --scan_libraries.  This option is purely for diagnostic purposes.  It allows you to easily confirm which library supplies the implementation of a function.

    More background on this general topic can be found in this stackoverflow thread.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 720 points

    George Mock said:

    I am not certain about some details of your case.  I presume the function canMessageNotification is weak in one library and strong in the other.

    Yes, canMessageNotification is weak in src\hal\hal.a<HL_notification.c.1.obj> which is HALCoGen generated and strong in src\can.a<can.c.1.obj>, which is my implementation.

    George Mock said:

    TI ARM assembly tools manual for the sub-chapter titled Exhaustively Read and Search Libraries.

    More background on this general topic can be found in this stackoverflow thread.

    Thanks for the links, I will read it and come back if needed.

    George Mock said:

    Even so, which implementation is used by the linker is not affected by the weak or strong attribute.

    Without having now read both links, I am bit confused now. Just to put it my words, to see that I fully understood that: I can not rely that in linked binary the strong implementation is used?

    One additional question: Is there an option for --scan_libraries that Shows, which library provides weak and strong implementations of a function?

    Thanks for your answers!

  • 0 in reply to user6135372
    TI__Guru**** 232670 points

    user6135372 said:
    Just to put it my words, to see that I fully understood that: I can not rely that in linked binary the strong implementation is used?

    When both the strong and weak implementation are not in library, then the strong one is used.  But if the choice is between one not in a library, and one in a library, the library one loses every time. If both are in a library, then the rules regarding libraries apply, and not strong or weak.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 720 points

    George Mock said:

    When both the strong and weak implementation are not in library, then the strong one is used.

    The not is not meant to be in that sentence I guess? If this is typo, as I think, then I get it. Thanks!

  • 0 in reply to user6135372
    TI__Guru**** 232670 points

    user6135372 said:
    George Mock

    When both the strong and weak implementation are not in library, then the strong one is used.

    The not is not meant to be in that sentence I guess? If this is typo, as I think, then I get it. Thanks!

    I typed it correctly the first time.  The only condition under which strong defeats weak is when both symbols are implemented in application level object files, and do NOT come from a library.  Otherwise, the rules regarding libraries apply.  I realize that means a weak symbol in an application level object file defeats a strong symbol in a library.  While that may be counter-intuitive, that is how it works.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 720 points

    Then it is cleary to me how this works.

    Many thanks and best regards.