• State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 21 subscribers
  • Views 2824 views
  • Users 0 members are here
2025 survey

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.

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

What does this warning mean?

Mohammad Adel

When I 74compile my project I get these errors:
****************************************
*** WARNING L1: UNRESOLVED EXTERNAL SYMBOL
SYMBOL: ?C_STARTUP
MODULE: gf.obj (GF)
*** WARNING L1: UNRESOLVED EXTERNAL SYMBOL
SYMBOL: ?C?COPY
MODULE: gf.obj (GF)
*** WARNING L2: REFERENCE MADE TO UNRESOLVED EXTERNAL
SYMBOL: ?C?COPY
MODULE: gf.obj (GF)
ADDRESS: 0027H
******** WARNING L1: UNRESOLVED EXTERNAL SYMBOL
SYMBOL: ?C_STARTUP
MODULE: gf.obj (GF)
*** WARNING L1: UNRESOLVED EXTERNAL SYMBOL
SYMBOL: ?C?COPY
MODULE: gf.obj (GF)
*** WARNING L2: REFERENCE MADE TO UNRESOLVED EXTERNAL
SYMBOL: ?C?COPY
MODULE: gf.obj (GF)
ADDRESS: 0027H
*******************************************
What does this mean and where is the problem?

Thanks

Parents
  • 0 in reply to Andy Neil

    Therefore, all the Linker sees is assembler-generated object files - so it has no reason to include any 'C' runtime!

    I tend to consider that conclusion to be caused by what IMHO is a defect in the toolchain.

    Why should the assembler (and the C compiler in SRC mode) be unable to put the same magic cookie into the .obj file that C51 in normal operation will put in there, to make the linker aware that the C runtime is needed?

    I've said this before: if inline assembly is supported, the assembler has to be capaple of to generating exactly the same object files you currently get from directly building object files in the compiler. Including debug info, linker hints, and whatever else there is. I.e.

    C51 SRC {options} foo.c
A51 foo.src

    should be guaranteed to produce the same foo.obj you get from

    C51 {options} foo.c

Reply
  • 0 in reply to Andy Neil

    Therefore, all the Linker sees is assembler-generated object files - so it has no reason to include any 'C' runtime!

    I tend to consider that conclusion to be caused by what IMHO is a defect in the toolchain.

    Why should the assembler (and the C compiler in SRC mode) be unable to put the same magic cookie into the .obj file that C51 in normal operation will put in there, to make the linker aware that the C runtime is needed?

    I've said this before: if inline assembly is supported, the assembler has to be capaple of to generating exactly the same object files you currently get from directly building object files in the compiler. Including debug info, linker hints, and whatever else there is. I.e.

    C51 SRC {options} foo.c
A51 foo.src

    should be guaranteed to produce the same foo.obj you get from

    C51 {options} foo.c

Children
  • 0 in reply to HansBernhard Broeker

    "I tend to consider that conclusion to be caused by what IMHO is a defect in the toolchain."

    The phrase "Not-Entirely-Integrated Development Environment" (NE-IDE) springs to mind, once again... ;-)

  • 0 in reply to Andy Neil

    Not quite...

    First of all, the IDE is quite innocent in this case. It's a problem of the command line tools and how they (fail to) interact.

    Second, as I see it it's not really a problem of "not entirely integrated" at all, but rather one of the tools being more integrated than does them any good. There's an object file generator integrated into the compiler, which I'm arguing shouldn't be there. It's duplicate maintenance work for Keil, causes unnecessary confusion on users' side, and reduces versatility of the toolset.

    Ceterum Censeo SRC esse fixatum "ON" (and the assembler upgraded accordingly).