• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 1142 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.

Linking to RTSC static library

1970135
Intellectual 285 points

My application consists of two projects.  The first is an abstraction library that hides details of OS and hardware.  The second is an executable that uses the abstraction library.  In this manner I am hoping to make the code for the executable platform independent, because it doesn't directly call any platform specific APIs, it just utilized services of the abstraction library.

This worked well for the Win32 build (where I have a VS solution consisting of one exe project that links to a static library project that is the abstraction layer).

Now am I trying to do this for a TI platform using CCS.  I have the abstraction layer as an RTSC static library.  I am hoping to isolate any calls to platform specific issues into this, e.g. use of SYS/BIOS features.  Then I have a standard CCS executable (non-RTSC) that links to the abstraction library.

So far I have had success building the static library.  I have also been able to compile the executable project.  However when I get to the link step for the executable project, it fails, e.g. I get the following error related to my use of sockets:

undefined                      first referenced                                                                           
  symbol                            in file                                                                                
 ---------                      ----------------                                                                           
 accept                         Debug\AlTiLibProj.lib<Tcp.obj>      

I am able to get past the initial set of link errors by hunting down individual libraries (e.g. C:\ti\ndk_2_22_03_20\packages\ti\ndk\stack\lib\stk.ae66) and having the executable project link to them, but that just pushed the failure to some other link errors.  I suppose I could do this over and over, but this seems fragile and probably not the correct way to be doing it.

Other details:

I have associated the executable project with the static library project by:

<executable's project properties> -> Build -> Dependencies -> <added static library>

<executable's project properties> -> Build -> C6000 Linker -> File Search Path -> Include library file or command file as input -> <added static library>

CCS v5.5.0.00077

TI compiler v7.4.6

I have seen the following link but I wasn't able to use it to do what I want, nor did it convince me that what I am trying to do is impossible (although perhaps it should):

http://e2e.ti.com/support/embedded/bios/f/355/t/297814.aspx

Since this is a linker issue I am first asking here, although it does involve other technologies (RTSC, SYS/BIOS, etc), so if you think another forum would be more appropriate (CCS or RTOS) I will try elsewhere.

  • 0
    TI__Guru**** 253230 points

    1970135 said:
    This worked well for the Win32 build (where I have a VS solution consisting of one exe project that links to a static library project that is the abstraction layer).

    I'm not sure, but I think this project created some expectations that cannot be met.

    1970135 said:
    My application consists of two projects.  The first is an abstraction library that hides details of OS and hardware.  The second is an executable that uses the abstraction library.

    That's a good way to organize your code.  But keep in mind that abstraction library is not self contained.  It calls many other functions which are not defined within it.  Those functions have to be supplied somehow.

    In your Win32 project, I suspect all the functions called by your abstraction library are supplied somewhere within the collection of libraries bundled with the compiler.  This is not the case with the TI tool chain.

    The TI compiler comes bundled only with the basic RTS functions specified by the ANSI standard, i.e. memcpy, strcmp, that sort of thing.  Anything else, such as ...

    1970135 said:
    undefined                      first referenced                                                                           
      symbol                            in file                                                                                
     ---------                      ----------------                                                                           
     accept                         Debug\AlTiLibProj.lib<Tcp.obj>      

    ... are supplied in different libraries that are not bundled with the TI compiler.  One way or another, those libraries must be available to the project.

    TI recognizes this can be cumbersome, so it bundles several related libraries together into software development kits (SDK) like the Multicore SDK.  An SDK usually comes with examples that you can build on, and buried within those examples is all the details of referring to the several different libraries in the kit.  

    Hope this helps ...

    -George

  • 0 in reply to George Mock
    Intellectual 285 points

    Thanks for the info Mr. Mock.

    On the Win32 side, the functionality I liked was not having to think about the abstracted components' implementations (e.g. Ws2_32.lib for sockets) in my exectuable project: I didn't need to (explicitly) link the executable project to the socket library, just to the abstraction layer static library.  Perhaps my compiler (Visual Studio) was using a librarian/archive tool to include the needed sockets functionality into the abstraction layer static library output.

    For TI, the approach we have taken so far (which we seem to be having some initial success with) is to setup the RTSC .cfg as required in the abstraction layer static library project.  Then in the executable project (now forced to be an RTSC executable project instead of a plain CCS executable project), put a file-level link to said .cfg file.

    Another approach might be to just role all the source into one RTSC executable project.  As long as we keep the thinking of the design as an abstraction layer and an application, we could still keep a clean sepperation of concerns for portability.  Maybe it's not too bad that they would all be one project for the TI platform.