• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 1660 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.

Original question:

CCS/MSP430F5529: error #10234-D: unresolved symbols remain

Compiler/TMS320F28335: Unresolved symbols remain: _memcpy. Issue only when compiling and linking with C2000 - ti-cgt-c2000_18.1.4.LTS cl2000.

Subha Viswanathan0
Prodigy 160 points
Part Number: TMS320F28335

Tool/software: TI C/C++ Compiler

Hi,

We inherited a project that was built using the C2000 compiler version 5.1.3.

Now trying to build the same project using the  ti-cgt-c2000_18.1.4.LTS version, I get the error 'Unresolved symbols remain: _memcpy'.

The compile and link flags used are as below:

:CompileOption
-g -d"_DEBUG" -d"LARGE_MODEL" -ml -v28 --float_support=fpu32

:LinkerOptions
-c -heap0x800 -stack0x7B0 -w -x -priority

Now, with the exact same options, the compiler version V 5.1.3 builds our source code without issues. 

However with the compiler ti-cgt-c2000_18.1.4.LTS, unresolved references are thrown for some standard C functions.

Now, if I explicitly link the library rts2800_fpu32.lib using the -l options, the errors go away.

Looking at the compiler guide,  Section 4.3.1.1 Automatic Run-Time-Support Library Selection below, my assumption is that the RTS will be automatically selected.

"If the linker assumes you are using the C and C++ conventions and the entry point for the program
(normally c_int00) is not resolved by any specified object file or library, the linker attempts to automatically
include the most compatible run-time-support library for your program. The run-time-support library chosen
by the compiler is searched after any other libraries specified with the --library option on the command line
or in the linker command file. If libc.a is explicitly used, the appropriate run-time-support library is included
in the search order where libc.a is specified."

My question is how are these 2 compilers different with regards to this issue. I am needing it to justify the changes I am making and for a clear understanding going forward.

Thank you,

Subha

  • 0
    TI__Guru**** 245180 points

    How do you conduct the build of the project?  With make, CCS, or something else?  If with CCS, then what version of CCS?

    Please conduct the problem build again.  Capture, with copy-n-paste of the text, the full invocation of the link step.  Show that invocation in your next post.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 160 points

    Hi George,

    I use a make file to build the project. Version of CCS installed is : 8.3.0.00009.

    This is the linking step on the make file:

    C:\Test\Implementation\BuildFile>cl2000 -v28 -z -c -heap0x800 -stack0x7B0 -w -x -priority -m"c:\Test\SOURCE\Debug\Project.map" -o"c:\Test\Debug\Project.out" c:\Test\Debug\*.obj -i"c:\Test\SOURCE" -l"c:\Test\SOURCE\F28335.cmd"

    Hope this helps.

    Thanks,

    Subha

  • 0 in reply to Subha Viswanathan0
    Prodigy 160 points
    Oh I missed this RTL that was built internally: rts2800_FlashAPI.lib

    C:\Test\Implementation\BuildFile>cl2000 -v28 -z -c -heap0x800 -stack0x7B0 -w -x -priority -m"c:\Test\SOURCE\Debug\Project.map" -o"c:\Test\Debug\Project.out" c:\Test\Debug\*.obj -i"c:\Test\SOURCE" -l"c:\Test\Lib\QualRTL\rts2800_FlashAPI.lib"

    When I edit the above to also add the standard library like the following, it builds without issues.

    C:\Test\Implementation\BuildFile>cl2000 -v28 -z -c -heap0x800 -stack0x7B0 -w -x -priority -m"c:\Test\SOURCE\Debug\Project.map" -o"c:\Test\Debug\Project.out" c:\Test\Debug\*.obj -i"c:\Test\SOURCE" -l"c:\Test\SOURCE\F28335.cmd" -l"c:\Test\Lib\QualRTL\rts2800_FlashAPI.lib" -l"c:\Test\Lib\rts2800_fpu32.lib"
  • 0 in reply to Subha Viswanathan0
    TI__Guru**** 245180 points

    Subha Viswanathan0 said:
    Oh I missed this RTL that was built internally: rts2800_FlashAPI.lib

    I don't recognize that library name.

    Subha Viswanathan0 said:
    When I edit the above to also add the standard library like the following, it builds without issues.

    I presume this resolves your problem.  Though I will add a few comments.

    Subha Viswanathan0 said:
    l"c:\Test\Lib\rts2800_fpu32.lib"

    I presume you copied this RTS library from the compiler install location to this directory.  That is not how it is usually done.  With recent compilers you typically use these two options ...

    -iC:\ti\ccsv8\tools\compiler\ti-cgt-c2000_18.1.4.LTS\lib
-llibc.a

    The first option specifies where the compiler RTS libraries are located.  That directory is typically where the compiler located within the CCS installation.  In a makefile, you usually assign the location of the compiler to a variable, then write something like -i$(COMPILER_ROOT)/lib .  The second option tells the compiler to automatically select the best RTS library.  It selects from the libraries in the location given by the first option.  This is a more robust solution the hard-coding the name of the library.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 160 points

    Thanks George.  This brings me to my first question again. How did C2000 V 5.1.3 resolve these standard library functions without having to explicitly specify via the linker (-l) but the latest ti-cgt-c2000_18.1.4.LTS expects it to be explicitly specified?

  • 0 in reply to Subha Viswanathan0
    TI__Guru**** 245180 points

    Version 18.1.4.LTS does not expect the library to be explicitly specified.  But you do have to indicate, usually with a -i option, what directory contains all the library files, including libc.a.  The same is true of version 5.1.3.  

    Is it possible that the version 18.1.4.LTS linker is somehow trying to read the libc.a from the 5.1.3 installation?  I would not expect that combination to work.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 160 points

    Hi George,

    As far as I can tell, version 18.1.4.LTS linker is NOT reading the libc.a from the 5.1.3 installation.

    Here are some other tracking that I have done since.

    In the project we have inherited,

    1.We have a __memcpy_ff defined explicitly in our project. This file (memcpy_ff.c) is being built (compiled/linked) and is being archived into the library say rts_mem.lib. This library is being linked to in our main project using the -l option.

    2. While building with the V5.1.3 compiler, I see the following in the map file.

    MATH_API 0 003259ae 000000bf RUN ADDR = 0000988a

    003259ae 00000034 rts_mem.lib : cos_f32.obj (.text)

    003259e2 00000034 : sin_f32.obj (.text)

    00325a16 0000002b : memcpy_ff.obj (.text:___memcpy_ff)

    00325a41 0000001e : memcmp.obj (.text:_memcmp)

    00325a5f 0000000e : memset.obj (.text:_memset)

    In the Global symbols section, I see

    GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name

    000098f2 ___memcpy_ff

    There is NO reference to _memcpy anywhere.

    3. Now when I try to build the same using V18.1.4 LTS, I get Unresolved symbols remain _memcpy. Now like you had said before, I linked libc.a. Builds successfully.

    Examining the map file, I see the following differences:

    MATH_API 0 00325b4e 00000094 RUN ADDR = 00009850

    00325b4e 00000034 rts_mem.lib : cos_f32.obj (.text)

    00325b82 00000034 : sin_f32.obj (.text)

    00325bb6 0000001e : memcmp.obj (.text:_memcmp)

    00325bd4 0000000e : memset.obj (.text:_memset)

    Notice that the  memcpy_ff.obj (.text:___memcpy_ff) is no longer seen.string_V18.1.4LTS.h

    And in the Global symbols, I do not see any __memcpy_ff but _memcpy.

    Now it is clear that somehow the __memcpy_ff definition is no longer used. But wondering what is used as a switch to determine if __memcpy_ff or _memcpy would be used.

    String.h file in V5.1.3 and V 18.1.4 LTS are attached.

    It would be great if you could tell me how the compiler chooses to use _memcpy (Nowhere to be seen) Vs  __memcpy_ff.

    Much appreciate your response.

    Thanks,

    Subha

  • 0 in reply to Subha Viswanathan0
    Prodigy 160 points

    I think my issue is tracked down. The new compiler calls memcpy instead of memcpy_ff that the old compiler called. This is shown in the assembly listing file that I generated from a sample source file using both the compilers. That was the issue.