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.

Codec Engine Shared Utilities Library

Hello,

I have two codec engines that build for Linux86, C64P and MVArm9.

I would like to have a library that has utility functions in it such as trace, memory management, etc.

How can I build the utility library for the multiple platforms and add it to the codec engine XDC build process so it sits in the .tar alongside the built codec engine library?

I can then specify the utility library in the package.xs , right? Do I set up the utility library build with XDC?

I tried just including the shared utility .c files when building into each codec engine but there are errors because one builds it and the other complains that it is already built.  This lead me to think that have a utilities.a64P alongside the codec.a64P would be the best thing.

Is there anyone that can help me with this?

Matt

  • If you're looking to create a 2nd library in the same package, it may be as simple as adding a second call to Pkg.addLibrary() in your package.bld script, and returning that 2nd library (in addition) in your package.xs's getLibs() fxn.  (Note that getLibs() returns a semi-colon delimited list of library names, so you can return more than one.)

    Pkg.addLibrary() adds a library to the build model.  See some of the package.bld and package.xs scripts throughout Codec Engine for some reference, and feel free to post followups.

    If you think this utilities.a64P is better suited as a standalone package (so multiple codecs could use it), you might create your own "clarkson.matt.codecutils" Package and build that instead.  You'd need your own package.xdc, package.bld, package.xs and utility.c file, but it'd fit in just like all the other utility libraries.  Your codecs would need to both #include <clarkson/matt/codecutils/utility.h> in their sources and declare a Package dependency in their package.xs scripts (e.g. in close() method, they could xdc.loadPackage('clarkson.matt.codecutils');).  Slightly more advanced, but encourages reuse of that utility library.

    Chris

  • Hey Chris, you always answer my posts!  Thank you.

    I think it would be perfect if I can build it into a utilities.a64P library.

    I have only ever set up a Codec engine XDC package but from what you say I can just set it up with the package* files and a single utilites.{c,h} and build it like that?

    I am pretty at easy with creating a XDC package so will now need to learn how to link the module!

    So say I have clarkson.matt.codec and clarkson.matt.utils and wanted to use the utilities.

    I would include <clarkson/matt/utils/utils.h> into my clarkson.matt.codec C file.

    • As that will be in the same namespace as my clarkson.matt.codec it will find that file, right?

    Now to link the library I need to do xdc.loadPackage('clarkson.matt.utils');.  Does this need to be done in my clarkson.matt.codec's package.bld?  For example:

    var Utils = xdc.loadPackage('clarkson.matt.utils');

    • What do I do with that xdcScript variable then?
    • Do I have to include the module into my package variable somehow?
    • How does the XDC know how to find that module?
    • Will it find it because it is in the same build namespace?

    Also you mentioned the close() method?  I have never seen that!  I've only ever seen getLibs(prog) in package.xs.

    Sorry for all the questions, never done this before! Hope it's not too much!

    Thanks,

    Matt

  • Matt Clarkson said:

    So say I have clarkson.matt.codec and clarkson.matt.utils and wanted to use the utilities.

    I would include <clarkson/matt/utils/utils.h> into my clarkson.matt.codec C file.

    Right

    Matt Clarkson said:
    As that will be in the same namespace as my clarkson.matt.codec it will find that file, right?

    Fundamentally, when compiling your codec (that #include <clarkson/matt/utils/utils.h>), the compiler needs to find your utils header on the include path.  XDC automatically places the XDCPATH on your include path, so just getting your XDCPATH set correctly is enough.  This distinction is interesting b/c someday you might want to ship clarkson.matt.utils in a completely separate product... yet still consume it from clarkson.matt.codecs.  So long as you set XDCPATH right, they can exist completely independent of each other, and wherever you like on your system.

    Matt Clarkson said:
    Now to link the library I need to do xdc.loadPackage('clarkson.matt.utils');.  Does this need to be done in my clarkson.matt.codec's package.bld?

    Not in the codec's package.bld, but rather its package.xs.

    The clarkson.matt.codec package (via its package.xs's close() method) should declare its dependency on the clarkson.matt.utils package.  This way, consumers of your clarkson.matt.codec package 1) don't need to know about dependencies in your codec, and 2) the ultimately generated linker cmd file will know about these dependencies and be able to order your libs correctly.

    If you grep for 'close' in the Codec Engine's package.xs scripts, you'll find some examples of close() being used.

    Matt Clarkson said:

    var Utils = xdc.loadPackage('clarkson.matt.utils');

    • What do I do with that xdcScript variable then?
    • Do I have to include the module into my package variable somehow?
    • How does the XDC know how to find that module?
    • Will it find it because it is in the same build namespace?

    This xdc.loadPackage() line will be in your codec pkg's package.xs close() method.  You won't need to assign it to a var (e.g. Utils in your example), b/c you're not going to do anything further with it.

    XDC will find that package along the XDCPATH.

    Chris

  • Thanks for all the information Chris.

    I manage to get everything I talked about working.  My codecs link my utils XDC module in their close() method.

    However, my program crashes when I try to call my trace function, which just does a simple printf().  I thought it was something wrong with the linking, but after reading your answer it seems as though that part is working correctly.

    I'll have to debug some more, I'm caught up in something else so had to stop development on that for now :(

  • Thanks, Chris, I resolved this.