linking a selected rts674 lib to the codec server

Joern

I have a small running test project for DM8148, built by EZSDK 5.03.01.15, within that project a DSP-side library written in C++ is wrapped by a small C API, to get it accessed from a codec, which then provides these functions via Codec Server and Codec Engine to the ARM side.

Now I have to add exceptions to the mentioned DSP-side C++-library - to be able to use existing C++ implementations without code rewrite (which makes sense at least for the initialization part, which is not time-critical). I translate my small C++-library (with its C wrapper) with option '--exceptions', and link it, again, to my codec. So far, so good. But now, when I want to link the codec server (at the moment containing nothing but this my own codec) I get error messages about some functions, which obviously concern exception handling.

It was no far way to realize that an other version of rts674 library is needed (instead of rts6740_elf.lib). In the meanwhile I've got built the rts6740_elf_eh.lib, by use of the comfortable mklib tool.

But how to configure it that the build process for the codec server (based on the TI's all_codecs sample) actually uses rts6740_elf_eh.lib instead of rts6740_elf.lib?

Thanks in advance,
kind regards,
Joern.

over 13 years ago

0 Robert Tivy over 13 years ago

TI__Mastermind 18260 points

Joern said:

But how to configure it that the build process for the codec server (based on the TI's all_codecs sample) actually uses rts6740_elf_eh.lib instead of rts6740_elf.lib?

Joern,

The specification of the RTS library with which to link is part of the XDC tooling. The module ti.targets.elf.C674 contains an element named lnkOpts that specifies linker options, and its default is this:

C674.lnkOpts = ITarget2.Options {

prefix: "-w -q -u _c_int00",

suffix: "-c -m $(XDCCFGDIR)/$@.map -l $(rootDir)/lib/rts6740_elf.lib"

};

See here for reference:

http://rtsc.eclipse.org/cdoc-tip/ti/targets/elf/C674.html

You can change this value in your config.bld file, either setting it completely anew or modifying the existing value somehow, perhaps as in:
var C674elf = xdc.useModule('ti.targets.elf.C674');

C674elf.lnkOpts.suffix = C674elf.lnkOpts.suffix.replace("rts6740_elf", "rts6740_elf_eh");

Regards,

- Rob

0 Joern over 13 years ago in reply to Robert Tivy

Genius 3055 points

Rob, you made my day, thank you very much!

I'll have to look deeper into all that in the next time to come to a point answering those questions by myself.

But however, thanks to your hint I just added the replace for the lnkOpts.suffix within _config.bld of my codec server and now my project links successfully with '--exceptions' enabled for a small lib bound into my codec. Yet I'll have to investigate how good it works (speed, robustness), but at least now I am enabled to use existing C++ modules with exception handling, too.

Best regards,
Joern.

0 Robert Tivy over 13 years ago in reply to Joern

TI__Mastermind 18260 points

Joern,

You're welcome, glad to help.

I have since learned that the following will also work:
suffix: "-c -m $(XDCCFGDIR)/$@.map -l $(rootDir)/lib/libc.a"
and is preferred since it lets the linker decide the appropriate RTS library. XDC tooling will be moving to this usage in the near future.

Regards,

- Rob

0 Joern over 13 years ago in reply to Robert Tivy

Genius 3055 points

Rob, thanks for this hint - I will try that out, and am curious concerning the results: because I am all but sure, if my constellation actually will be handled that automatically by the XDC tools. I have:

a codec server, based on TI's all_codecs example
a codec, in parts based on the universal_codec example
that codec (resp. it's IUNIVERASAL core) calls functions from a C library
that C library actually is a wrapper around a C++ library

The C wrapper and the C++ modules are compiled with the --exceptions option, the whole library build is controled by a good, old GNUmake makefile. As good and flexible the concept of the XDC tools may be, I have not to be such flexible concerning lots of TI hardware variants. But I have to deal with a huge amount of existing code within a makefile build system, which is prepared to be translated for lots of operating systems and some more or less fixed platforms being typical for our product.

That library is bound to the codec by xdc.loadPackage() and told about also by the #include statement within the IUNIVERSAL implementation.

So the XDC tools would have to analyse the binaries of all that way built and bound libraries concerning those features as exceptions being enabled to decide which standard library versions should be bound. Maybe they do; in principle anyway the linker has to do those things. And if they do, I'd welcome that, of course, because the error messages concerning library conflicts might come earlier and would probably become more dedicated to the causing libraries.

Kind regards,
Joern.

0 Robert Tivy over 13 years ago in reply to Joern

TI__Mastermind 18260 points

Joern,

I found this other Forum thread discussing the libc.a feature: http://e2e.ti.com/support/development_tools/compiler/f/343/t/85635.aspx

As you can see, this feature has nothing to do with XDC tools. The "suffix" specification that I referenced is merely XDC's "window" into standard C/C++ compiler/assembler/linker options.

This might also help, in case you want to create such an "index archive" for your own libraries: http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spru186&track=no. Check out section 6.5 - Library Information Archiver Description.

Regards,

- Rob

0 Joern over 13 years ago in reply to Robert Tivy

Genius 3055 points

Thanks, Rob, these hints actually helped to clarify some open questions in my mind.

Obviously the libc.a in the EZSDK (yet using 5.03.01.15) has been pre-build for more library versions than actually delivered (if not for all possible versions).

Interestingly, using libc.a but with removed rts6740_elf_eh.lib (which I had built by use of mklib) I get these messages:

lnke674 bin/ti_platforms_evmDM8148/codecserver_DSP.xe674 ...
warning: automatic library build: using library
   "/somewhere/ezsdk/dsp-devkit/cgt6x_7_3_1/lib/rts6740_elf_eh.lib" for the
   first time, so it must be built.  This may take a few minutes.
>> ERROR: mklib: could not open /somewhere/ezsdk/dsp-devkit/cgt6x_7_3_1/lib/rts6740_elf_eh.lib for writing: Permission denied
warning: automatic RTS selection:  resolving index library "libc.a" to
   "/somewhere/ezsdk/dsp-devkit/cgt6x_7_3_1/lib/rts6740_elf_eh.lib", but
   "/somewhere/ezsdk/dsp-devkit/cgt6x_7_3_1/lib/rts6740_elf_eh.lib" was not
   found

That means: if my location 'somewhere' was not (intentionally) protected against writing, and if already using libc.a to be linked, then I probably never had realized that after changing my wrapper library to support exceptions the linkage of the codec resp. codec server this library was missing: it calls mklib automatically.

First of all: I feel that to be very comfortable.

But that automatism should be pointed out at a central place (as the comfortable mklib itself, too).

Also I feel the XDC resp. RTSC configuration being very comparable to so-called frameworks which I know from web programming: it deliveres much comfort by automation, but if you have a need deviating from the main stream (or if some usual detail not yet is considered within the framework), then too often configuration tends to be a nightmare: Because the framework's configuration easily can be overloaded at so much places, it is difficault to localize the actually active configuration source, the corresponding intentions and the best place for own configuration changes. I mean, that in this point yet is something to do for the EZSDK...

Thanks again,

Joern.

Processors

Processors forum

linking a selected rts674 lib to the codec server