• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 54 subscribers
  • Views 1541 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linker Error unresolved symbol after modifying StarterWare Example with own sourcefile

Janos Buttgereit
Intellectual 260 points


Hi,


I recently started learning to programm the AM335x SK with Bare Metal Code. I use CCS 6.1.2 on Linux with the Sitara StarterWare. My idea was to take the enetEcho example from the StarterWare and modify it to support UDP communication.
So I took the enetEcho example and wrote my own code in a new udpServices.cpp sourcefile and added a folder with the name "include" wich contains the udpServices.h header file. I added "${workspace_loc:/${ProjName}/include}" to the compiler's include search path and to the linker library search path (not sure if this was right).

I changed enetEcho.c to enetEcho.cpp as I'm planning to use some C++ in the project and added #include "udpServices.h" to that file before calling my own function in the main.


Now, when I try to build the project, wich worked fine before I added my function to enetEcho.cpp, I get the Linker error 

unresolved symbol udp_service_init, first referenced in ./enetEcho.obj	enetEcho		 	C/C++ Problem

Since now, I always created small projects with CCS, that worked immediately, so I have no idea of how to configure my project, so that my own sourcefiles are found by the linker. On the Internet I just found a lot of answers dealing with the usage of TI or third party libraries, but not with own source files.

  • 0
    Intellectual 260 points
    I found the solution by myself. Adding "${workspace_loc:/${ProjName}/include}" to the compiler's include search path was right, but adding it to the linker library search path was wrong. As the linker looks out for the source file, which I put into the main Project folder, changing the linker library search path to "${workspace_loc:/${ProjName}}" solved the problem!
  • 0 in reply to Janos Buttgereit
    Intellectual 260 points
    Sorry. It seemed to be the solution, but I had to realize that I just forgot a bracket at the end of the search path. Looking closely at the Build console showed me, that it didn't finish building because of that. So, I'm still looking for a solution.
  • 0 in reply to Janos Buttgereit
    TI__Guru**** 173310 points

    Janos Buttgereit said:
    So, I'm still looking for a solution.

    Can you please explain what the remaining problem is? Are you still getting the unresolved symbol error?
    It would be helpful to see the full output of the CCS build console (you can copy it to a text file and attach it here).

  • 0 in reply to AartiG
    Intellectual 260 points

    Thank you for your reply, AartiG.

    I was still getting the unresolved symbol error. But the solution turned out to be something completely different.

    As I planed to use C++ Code to extend the example Project, I renamed the enetEcho.c to enetEcho.cpp first, compiled it to see if that works and thought "C++ seems to be no problem" as compiling worked without any errors. So I added my C++ sourcefile to the project, wich didn't actually include any C++ code at that time and called a function from that source file in the main.


    What I didn't realize was, that I just renamed a LINK to enetEcho.c wich was placed in the Workspace but nut enetEcho.c itself, so it stayed a C source file. Including the function from a C++ source file then didn't work and created the error. After renaming my own source file to .c, everything compiled well.

    Now I still plan to add some C++ code to the Project. Trying to change the extension of the real source File in the File Browser to .cpp and modifying the link in the workspace led to a new, completely different Error, complaining about 

    #ifdef __TMS470__
#pragma DATA_ALIGN(pageTable, MMU_PAGETABLE_ALIGN_SIZE);
static volatile unsigned int pageTable[MMU_PAGETABLE_NUM_ENTRY];

    with "expression must be an integral constant expression". Seems to be something about the compiler now.

    So it seems that changing to C++ just is not as easy as changing the extension to .cpp. But as my new Problem isn't related to the title of this Topic anymore, it would maybe be better to open a new topic for that?

  • 0 in reply to Janos Buttgereit
    Guru 92251 points

    Janos Buttgereit said:
    So it seems that changing to C++ just is not as easy as changing the extension to .cpp.

    With the TI ARM compiler the syntax of some pragmas differs between C and C++. e.g. see 5.10.7 The DATA_ALIGN Pragma in the Compiler User's Guide.

    In which case to allow the DATA_ALIGN pragma to compile for C++ try changing to:

    #ifdef __TMS470__
#pragma DATA_ALIGN(MMU_PAGETABLE_ALIGN_SIZE);
static volatile unsigned int pageTable[MMU_PAGETABLE_NUM_ENTRY];

  • 0 in reply to Janos Buttgereit
    TI__Guru**** 173310 points

    Janos,

    Chester brings up a good point about the difference in syntax of pragmas between C and C++. If you face other compiler issues down the road in moving from C to C++, I would suggest starting a new post in the Compiler forum as the experts there can help best with those.

  • 0 in reply to AartiG
    Intellectual 260 points

    Great Chester, that solved my problems. I Just exchanged the pragma and wrapped the #includes for the .c source headers in extern "C" { } and now everything compiles without Problems!So a new post in the Compiler forum seems unnecessary now and I'm able to start coding now...