libxDot_mbed5 linker error in MBED online compiler

Home Forums mDot/xDot libxDot_mbed5 linker error in MBED online compiler

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #30629
    Justin Spangaro
    Participant

    Hi,

    I am working on code that has previously worked but adding in some code that includes the ostringstream library seems to have provoked a runtime linker error as follows:

    Error: Undefined symbol std::basic_ios<char, std::char_traits<char>>::basic_ios(const std::basic_ios<char, std::char_traits<char>>&) (referred from ../../build/examples/src/main.MTB_MTS_XDOT.o).

    Some investigation led me to these links which might give some clues. It looks like maybe the library was compiled with an old compiler version.

    https://os.mbed.com/questions/79541/Problems-linking-against-xDot-library/
    https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

    The code is built with libxDot_mbed5

    Any suggestions how to resolve (using the MBED online compiler)?

    Thanks.

    #30630
    Jason Reiss
    Keymaster

    The online compiler now uses ARMC6, there may be some logic to detect a library built with the previous version of ARM CC and compile with the previous version.

    Are you using an earlier version of libxDot_mbed5? Which version?
    What mbed-os version are you compiling with?

    Could you publish an example project showing the issue?

    I was able to compile this example with mbed-os-5.13.14 and libxDot 3.3.5

    
          ostringstream s1;
          int i = 22;
          s1 << "Hello " << i << endl;
          string s2 = s1.str();
          printf("%s\r\n", s2.c_str());
    
    #30631
    Justin Spangaro
    Participant

    Hi,

    (Read the update at the bottom first)

    Readme.md for the xdot library cites the version below.

    “# libmDot-dev
    Bleeding edge development version of the mDot library. This version of the library is not guaranteed to be stable or well tested and should not be used in production or deployment scenarios.

    This library is compaible with mbed-os version 5.1.3 and above.”
    ————————–
    According to this posting, the MBED online compiler (which I am using) automatically uses the latest version of mbed-os

    https://os.mbed.com/questions/78849/How-can-you-find-out-the-revision-of-mbe/

    When I click on mbed-os in the MBED online environment, it cites:

    Last Modified: 13 Jan 2020
    Revision: 5345:c966348
    status: synced

    ———————————

    I’d rather not publish the project to a public forum, however the code recently added looks something like this:

    ——————————————

    #include <iostream>
    #include <sstream>
    #include <iomanip>
    #include <list>
    #include “mbed.h”
    #include <string>
    #include <cstdio>
    #include <cstdint>
    #include <math.h> // modf

    using namespace std;

    // GpsReading class, which represents data of a GPS fix and
    // member functions to manipulate the data
    class GpsReading {
    public:
    std::string hexLatitudeString;
    std::string hexLongitudeString;
    //
    // other irrelevant stuff here removed from the example…
    //

    const uint8_t deviceType = 0x00; // 0x00 is default
    // note the default setting of deviceType
    // should be moved into a constructor..
    std::ostringstream loraPayloadString;
    // use ostringstream to construct the output string
    // ref https://stackoverflow.com/questions/29320434/convert-array-of-uint8-t-to-string-in-c

    // constructors and member functions

    // member function to convert a GPS reading data set into bytes ready to send to
    // the Lora transmitter
    std::string translateToSendBytes ();
    private:
    };

    string GpsReading::translateToSendBytes ( ) {

    //
    // other irrelevant stuff here removed from the example…
    //

    // using ostringstream class to construct the string
    // reference
    // https://stackoverflow.com/questions/29320434/convert-array-of-uint8-t-to-string-in-c

    string GpsReading::translateToSendBytes ( ) {

    //
    // other irrelevant stuff here removed from the example…
    //

    loraPayloadString << std::uppercase << std::hex << (int)deviceType;

    printf(“payloadString = %s”, loraPayloadString.str());

    return loraPayloadString.str();
    }
    —————————-

    A couple of footnotes:
    1. I believe I had made some other changes before I got pulled off the task and had to come back to it again after a while. It was compiling at an earlier revision of the design, but in the online environment who knows what can change, the compiler, the mbed-os library version all can change behind the scenes. So the ostringstream latest change could possibly be a red herring. But at the moment I am inclined to believe that it has to do with ostringstream.

    2. I have not test compiled the code fragment above which I hacked together from the code. Apologies for any bugs, hopefully illustrative at least.

    3. I just retested without changing anything. It seemed to recompile mbed-os but threw the same error. The error help points to the link below:
    https://os.mbed.com/cookbook/Compiler-Error-L6218E

    ////////// UPDATE /////////////////

    4. OK….after writing the above, I ran an “update” on mbed-os as it was not updated since Jan 2020, and now it comes up with a different compile-time complaint:

    Error: Cannot pass non-trivial object of type ‘std::__1::basic_ostringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >::string_type’ (aka ‘basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >’) to variadic function; expected type from format string was ‘char *’ [-Wnon-pod-varargs] in “examples/src/read_gnss_data.cpp”, Line: 352, Col: 38

    Line 352 was this line:

    printf(“payloadString = %s”, loraPayloadString.str());

    If I comment that line out, I hit a different bug which I am still investigating. So will share the details above for your info but I need to work on this a bit more to investigate if there is still an issue. It looks like the mbed-os library update seemed to make a difference at least.

    It is also obvious that mbed-os version needs to be updated manually, it is not automatic at all. The help here was a little ambiguous:
    https://os.mbed.com/questions/78849/How-can-you-find-out-the-revision-of-mbe/

    “Yes, I believe that the online compiler uses the “latest” branch by default…”

    Thanks.

    #30633
    Justin Spangaro
    Participant

    Hi again,

    Just to update, the compiler/linker errors I kept getting were not helpful enough to track down the problem. Suspecting that it was probably something subtle to do with libraries being stale, I rebuilt my design in a fresh space and reimported brand new xdot (production) and mbed-os libraries from github and my linker problems went away.

    I now have a design that builds to a binary, which it great. However, the compiler is still throwing out a cryptic-looking warning that looks ominously like there is something wrong with ostream

    To be honest, I can’t make any sense out of the warning.

    I will ignore this for now (until it bites me) but you might want to have a look, and if you can see what the problem is please let me know.

    I am working from the latest production version of the xdot library and the latest mbed os version (as of today), in the MBED online compiler environment.

    Warning: L6439W: Multiply defined Global Symbol std::__1::basic_ostream<char, std::__1::char_traits<char>>::sentry::sentry__sub_object(std::__1::basic_ostream<char, std::__1::char_traits<char>>&) defined in .text._ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC2ERS3_(/opt/ARMCompiler6.13.0.8/bin/../lib/libcxx/libcpp_w.l(ios.cpp.o)) rejected in favor of Symbol defined in .text._ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC2ERS3_(../../build/src/read_gnss_data.MTB_MTS_XDOT.o).

    • This reply was modified 3 years, 11 months ago by Justin Spangaro. Reason: added "linker" errors
    #30636
    Jason Reiss
    Keymaster

    Looks like that readme needs some work.

    The latest tag for mbed-os is mbed-os-6.0.0-beta-1

    The released library was built against mbed-os-5.15.1
    I suggest rolling back mbed-os to use mbed-os-5.15.1

    https://os.mbed.com/teams/MultiTech/code/libxDot-mbed5/

    The Dot library version and the version of mbed-os it was compiled against can both be found in the commit message for that revision of the Dot library. Building your application with the same version of mbed-os as what was used to build the Dot library is highly recommended!

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.