• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 2744 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.

RTSC static library

Frank Steinhauser
Prodigy 30 points
Other Parts Discussed in Thread: SYSBIOS

Hi!

We want to use RTSC components (in particular, SYS/BIOS Queues) within a static library. This static library will be linked to an application that also uses RTSC components. There is an old (2011) thread on the E2E forum with a similar question (http://e2e.ti.com/support/embedded/bios/f/355/t/135669.aspx) where TI Employee Sasha Slijepcevic mentions "the library you are building must be a part of a RTSC package, if you are planning to link with that library in another RTSC project."

I wouldn't know this if I hadn't stumbled upon mentioned thread. Where in the RTSC documentation is that mentioned? The fact that I can successfully build an RTSC application linked to an RTSC static library (in contrast to the problem mentioned in the thread - there were unresolved symbols) confuses me even further.

I must say that the process of creating and maintaining own RTSC packages plus integrating those in our build process is something I'd like to avoid when possible... A team member has made some experiments, e.g. Lib + Application (both RTSC) with contradicting RTSC configuration settings, but hasn't really gone far. But anything he tried didn't really speak against RTSC static libraries. How should we proceed? Can someone please point us to the right chapter of the RTSC docs?

Regards,
Frank

  • 0
    TI__Mastermind 37985 points

    Frank,
    you haven't mentioned it in your thread if you are using CCS, but the root cause of the problems in the linked thread is that CCS does not support building RTSC packages. Users can build RTSC apps that use RTSC packages, but the packages itself are built outside of CCS and they are made available to the apps through various RTSC products that are installed with CCS. There are users who managed to build RTSC packages in CCS, but there is no documented way how to do it, and no related testing is done. I hope that CCS will eventually support the build of RTSC packages, but the requests for that functionality are still rare so there is no that much work done towards that goal.
    My comment in the linked thread is just restating that all RTSC content is delivered through packages. In RTSC Overview, we are describing that content producers are delivering RTSC content through packages, and in other places in the docs we specify that the packages are input to app builds, for example here http://rtsc.eclipse.org/docs-tip/The_RTSC_Flow#Phase_4_.E2.80.94_Configuration. I guess we are not being clear that the packages are the only way how the RTSC content is delivered.

    Now back to your actual question. As I said earlier, you should build your packages outside of CCS. It is an advanced topic and requires more involvement with RTSC than if you are simply consuming RTSC packages when building your app. The best place to start are the RTSC programming guides. Once you build your packages, put them in a repository and use them in your RTSC apps.

    There could be alternative solutions, but I would have to know more about your project(s). Are you delivering libraries to third partis or they are only used within your team to build RTSC apps? You can use the same set of source files in multiple CCS projects without copying them. You may prefer that instead of building RTSC packages.

  • 0 in reply to Sasha Slijepcevic
    Prodigy 30 points

    Sasha,

    thank you for your quick reply. Yes we are using CCS - for illustration the most basic setup is one static library project and one application project, both using RTSC. Actually I don't want to get into RTSC package building at all (if not necessary). We don't want to give away the libraries that use RTSC, it's just that our internal helper libraries happen to use RTSC packages (mostly XDC runtime and SYS/BIOS). We want the RTSC configuration for those libraries to be contained in the libs. We want to be able to just link a library and not care about any further RTSC config for that library.

    We also thought about just sharing source files across projects, but then the RTSC configuration would not be tied to the specific software part any more. All configuration settings would have to be made in the application project.

    To sum it up, the options for us are (descending from most attractive solution)

    1. Using RTSC application and link to RTSC static libraries as in our rudimentary experiments (please tell me about all reasons speaking against this)
    2. Sharing source files that just consume RTSC facilities (could not be compiled by themselves, no CCS project, no RTSC config file)
    3. Packaging our libs into RTSC packages (hard to build automatically as I see it now, considerable initial cost for setting this up)

    Regards,
    Frank

  • 0 in reply to Frank Steinhauser
    TI__Mastermind 37985 points

    Frank,
    I think the fundamental problem you are facing is that ideally you would want to use RTSC config once and generate some kind of a component that will be used in another RTSC config step when you build your app. However, there is only one config step in RTSC and it runs at the application build time. You can't really configure a library. You can build your object files, which will have undefined references to XDC runtime and BIOS, and then you add RTSC config files that run inside the RTSC config step and ensure that the symbols required by your library are generated at the app build time. That's what a RTSC package really is, a bunch of object code and RTSC config code that ensures that undefined symbols are correctly generated.

    I can believe that you successfully created two projects, one with a library and one with an app, where your library config code is in the app project. I know that you say that the config for the lib project is in that project, but the only way that would work is if the config script in the app project explicitly loads the config script in the lib project. Also, when you are building your lib project, the config script in that project can't be really used. The problem with that setup is that it's not supported or tested, and if you need to make some further changes or something goes wrong, it will be difficult and time consuming to debug it either for you or for us at TI. See the beginning of my previous post, where I was discussing that setup.

    That leaves options 2. and 3. You already mentioned why you would not want to use any of them, and I can see their problems. It's really up to you to weigh pros and cons of these 3 options.

    However, I want to mention one more option that may not work for your current project as it is, but if you find it attractive you could rearrange your project accordingly. I can't really tell what you meant with


    We also thought about just sharing source files across projects, but then the RTSC configuration would not be tied to the specific software part any more. All configuration settings would have to be made in the application project.

    That could mean that you have apps that share the config for the library, but they also have their own config scripts that differ from app to app. But, if you are building only one application, or you are building multiple apps but all of them use one common config script, you can encapsulate everything RTSC related into one component that you then link against multiple apps without any configuration. The tool that does that is called xdc.tools.closure. Take a look at the linked docs in case you think you can use it.

  • 0 in reply to Sasha Slijepcevic
    Prodigy 30 points

    Sasha,

    thank you for your help. We will go for the solution with RTSC symbols getting resolved in the application linking stage.

    You can build your object files, which will have undefined references to XDC runtime and BIOS, and then you add RTSC config files that run inside the RTSC config step and ensure that the symbols required by your library are generated at the app build time.

    But there remains a problem: When building these object files we depend on certain RTSC header files (e.g. <ti/sysbios/knl/Queue.h>) or else there are missing definitions. In a (properly configured) RTSC project i can just write #include <ti/sysbios/knl/Queue.h> and RTSC magic somehow sets the correct include paths for the compiler. In a non-RTSC project I don't have that magic (in the form of a compiler.opt) and I can't use RTSC include files at all unless I specify absolute paths in my CCS project files. Is there a better solution? If I instead made an RTSC project out of my library, I could at least use the include paths but for reasons already discussed libraries just shouldn't be RTSC projects. Am I getting something wrong here?

    Regards,
    Frank

     

  • 0 in reply to Frank Steinhauser
    TI__Mastermind 37985 points

    Frank,
    I think I was not clear enough. My first paragraph was just a general overview of how RTSC packages work and what actually happens when you configure the app with properly built RTSC packages. I wasn't really giving any specific advice how to make Option 1 work better. I just wanted to offer some background info that may be helpful if you proceed with Option 1, Option 1 being the setup that you have right now with building a library in a RTSC project in CCS with a config file.

    I don't think you would get any benefits by building your library in a non-RTSC CCS project. You already have something that works,even if an untested setup, so there is little to  gain by moving to another untested setup unless it solves a very specific problem for you that the first one can't.