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.

Compiler/TMS570LS3137: Incompatible with runtime support library

Part Number: TMS570LS3137

Tool/software: TI C/C++ Compiler

Hello.

I've planned to move to a newer compiler version (from v5.1.12). After choosing v15.12.4 I get the following error message:

error #10425-D: C++ or C object files built with compiler versions before
15.3.0 are incompatible with this version of the runtime support library.
Undefined symbols or runtime failures may result. (First detected in
"C:/perforce/SerielleKlemme/Basis_Source/TRDP_Prototyp/Firmware/eCLRLib/Rele
ase_ExecInPlace/eCLRLib.lib<mscorlib.obj>", compiled with version 5.1.7.)

Unfortunatly rebuilding the library isn't possible and I must use it as it is.

But if I choose v15.12.3 the build finishes without errors. So is it save to use v15.12.3, or does this version simply do not check for incompatibility?

Which is the newest compiler version compatible with the library built with v5.1.7?

Thanks

BR

Christian

  • Christian,

    5.2.8 and earlier compiler versions cannot interlink with later compiler versions due to an issue with RTS routine isnan() definition changing between the 5.2.x/5.1.x releases and 15.12.0.LTS (and future releases).

    A patch was applied to 5.2.9 that allows it to interlink with 15.12 and newer releases.

    The new diagnostic was added to 15.12.4.LTS and not to 15.12.3.LTS

    In regards to your question, the newest compiler that would still interlink without this issue is 5.2.9

    The only option for using a more recent compiler version would be to recompile your library with 5.2.9, 15.12.4.LTS, or any more recent release.

    Regards,

    Greg

  • Christian,

    Following up on this a bit, you mentioned 15.12.3.LTS links without any errors.  However, what should happen is 15.12.3.LTS should have link errors like below:

    <Linking>

    undefined first referenced
    symbol in file
    --------- ----------------
    _Dclass try1.5.2.8.obj
    _Dsign try1.5.2.8.obj
    _FDclass try1.5.2.8.obj
    _FDsign try1.5.2.8.obj
    _FFpcomp try1.5.2.8.obj
    _Fpcomp try1.5.2.8.obj

    And then 15.12.4.LTS link should emit above error as well as its diagnostic.

    <Linking>
    error #10425-D: C++ or C object files built with compiler versions before
    15.3.0 are incompatible with this version of the runtime support library.
    Undefined symbols or runtime failures may result. (First detected in
    "try1.5.2.8.obj", compiled with version 5.2.8.)

    undefined first referenced
    symbol in file 
    --------- ----------------
    _Dclass try1.5.2.8.obj 
    _Dsign try1.5.2.8.obj 
    _FDclass try1.5.2.8.obj 
    _FDsign try1.5.2.8.obj 
    _FFpcomp try1.5.2.8.obj 
    _Fpcomp try1.5.2.8.obj

    I'm trying to understand how you could get the diagnostic for linking with 15.12.4.LTS and yet no other errors. And then no errors for linking with 15.12.3.LTS

    Thanks
    Greg

  • Christian,

    The diagnostic you are getting has two possible explanations. And given you are not seeing any other linker errors (and none for 15.12.3.LTS), I think you are encountering the other issue for this diagnostic.

    Is your library C++?

    If your library is C++ then please see below README.txt details on the RTS change introduced with 15.12.0.LTS (v15.3.0.STS is the initial short term release for 15.12 release stream):
    --------------------------------------------------------------------------------
    10) STLport C++ RTS
    --------------------------------------------------------------------------------
    v15.3.0 introduces the STLport C++03 RTS. The move to STLport will break ABI
    compatibility with previous C++ RTS releases. Attempting to link old C++
    object code with the new RTS will result in a link-time error. Suppressing
    this error will likely result in undefined symbols or undefined behavior during
    execution. Breakages are known to occur in particular for object code using
    locale, iostream, and string.

    In most cases, recompiling old source code with the new RTS should be safe.
    However, for non-standard API extensions to the C++ library, compatibility is
    not guaranteed. This includes usage of hash_map, slist, and rope.

    Dependence between locale and iostream is increased in STLport. Usage of one
    will likely cause the other to be linked as well. This may cause an additive
    increase in both code size and initialization time.

    C ABI compatibility will not be affected by this change.  

    Regards,
    Greg

  • Hi Greg.

    Yes, the library is C++ but I don't know which APIs are used. I don't have the source code. But I definitly don't get linker errors.

    So for me the only possible way is to stay at 5.2.9

    Thanks for your reserach and help.

    BR

    Christian