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

ccsv5.2 - library overrides

JimG
Intellectual 560 points

I'm trying to adapt a project in which we have our own versions of some common functions - most notably printf, vprintf, and a couple of things from the NDK. The most immediate problem is that my printf version is colliding with one from miniPrintf in the NDK.  I really don't want miniPrintf at all.  I want the standard low level printf stuff, e.g. vsnprintf, so that I will have the normal quality of translation for things like floating point numbers.  Then I want to override vprintf and printf so that I can direct them to some of my own interfaces.  

This has worked in the past, e.g. CCS3.3 and NDK2.0.  Now I'm getting linker errors indicating the printf and vprintf are implemented both in my code and in miniPrintf.  Again, if at all possible, I would like to exclude miniprintf from my build.

Is there a simple way to make this happen?  

  • 0
    Intellectual 560 points

    I've continued experimenting with this, and I've learned a little bit more about it.

    I hand edited the linker.cmd file (shame on me...) and put the one -l of an object file at the bottom.  I believe this had the effect of deferring loads of anything from the libraries until the second pass over the libraries.  The result was that all of my overrides worked.

    Obviously, I can't do this all the time.  It seems like the only relevant tool for this would be the Link Order tab in Project Properties/Build.  That could be a real pain, though.  It seems like I would have to mention almost everything in my build in order to move linker.cmd to the end.

    Anyone have any ideas?

  • 0 in reply to JimG
    Expert 2210 points

    Since the C standard does not allow you to replace standard library functions themselves, what you should do instead is to use different names for your own functions.  You can use #undef printf; #define printf my_printf in your project header file (#included *after* <stdio.h>) in order to continue using the name"printf" in your existing source code without interfering with uses of the standard library function by third-party libraries etc.

    More usually, project source code invokes the function using a macro, e.g. PRINT, which is #defined as printf or my_printf depending on the circumstances.

     

  • 0 in reply to Douglas Gwyn
    Intellectual 560 points

    Actually, replacing standard C functions is exactly what miniPrintf in the NDK is doing.  I would happily rename my functions if that were the only problem.  But miniPrintf is being loaded, and its (reduced) versions of the standard functions - like vsnprintf, which I need - are in there instead of the more capable version from the standard library.

    I'm headed for the same problem with things from the NDK which I have to override.  I need to replace this with a custom version to support a private bootp protocol.

    As I've mentioned, if I hand edit the linker.cmd file, putting the -l of the object file at the bottom, that significantly changes the order of library searches, and allows my functions to come in the same way that they did previously under CCS3.3.  I really believe that all I need is a little more control during the linker step of the build, so that I can assure the order of object file and library processing.

  • 0 in reply to JimG
    TI__Guru**** 173310 points

    JimG said:
     It seems like the only relevant tool for this would be the Link Order tab in Project Properties/Build.  That could be a real pain, though.  It seems like I would have to mention almost everything in my build in order to move linker.cmd to the end.

    You actually don't have to specify all the files passed to the linker in the Link Order tab, only the critical ones whose orderings are important, are sufficient. I'm not sure how these printf/vprintf custom routines are being added to your project, but the key is that they should appear in the link command prior to the NDK if you want those to be used instead of the ones from the NDK. Usually the custom routines/C source files are simply added to the project and that should allow them to be picked up instead of the ones from the runtime library. However if that is not happening automatically you may need to tweak it a little using the Link Order tab.

  • 0 in reply to AartiG
    Intellectual 560 points

    Thank you!  I'll try that.

    Just for background, things went wonky due the fact that the generated linker.cmd file was the first thing in the link, and that it included the object file MC4_DSP_p64Pe.o64Pe as its first entry.  Following that in the linker.cmd file were a bunch of libraries, among them miniPrintf.  The object file had references to stuff in the libraries, so those things were pulled out of the libraries before my object files were examined.

    I would have preferred for linker.cmd to be processed last rather than first. 

    I also found during some experiments that if I hand edited linker.cmd after it was generated and moved MC4_DSP_p64Pe.o64Pe to the bottom, that would also make it possible for me to get my objects in before the libraries were searched.

    As I said, I'll try putting some critical stuff into Link Order and see if that cures it.

    Thanks again for your help.  I'll let you know how it turns out.

  • 0 in reply to JimG
    Intellectual 560 points

    Just to confirm, that did work.  I had to also include the linker.cmd file to force it lower in the list.

    I really think it would be best if the build tools put all object files before all library files in the link by default.  It's the most common practice.  The linker.cmd file, as it is now constructed and placed in the link departs from this tradition, and I don't think it is a good thing.