Since Studio updated itself to 1.4.6 I cannot compile Xdot code. 6 error are generated, all to do with LibXdot functions in mDot.h. This is a typical one: [Error] @0,0: L6218E: Undefined symbol mDot::send(std::__2::vector<unsigned char, std::__2::allocator > const&, bool const&, bool const&). 5 errors are for dot functions using vectors, one using string parameter.
This used to compile OK, now it won’t, and it still generates the same errors even if I update to the latest libXdot and mbed5.
Does anyone lese have the same problem, and is there a solution?
Hi Geoffrey, version 1.4.6 comes with a new license for the included Arm Compiler, but otherwise should be the same as 1.4.5.
You could try cloning the libxdot library again at the version you had when it worked, otherwise sharing more details about the project might help debug.
Thanks for the help, but actually although I might have been using 1.4.5 the tools were all out of date and I had previously had problems when I allowed an update. Unfortunately I have no record of the versions (the automatic update erased everything) and although I can download old versions of Studio they cannot be used because the licence has expired.
My software is quite large and complex so maybe I will try creating something smaller to see if there is still a problem which I can share more easily.
Still no progress! I’ve created a new workspace with just Dot examples for Mbed5 (LibXdot-mbed5) confirgured for OTA, EU868. After ironing out quite a few problems I still have the same basic compile problem showing “Undefined symbol mDot::send” and others mainly in mDot, but all (perhaps significantly) having a parameter “std::__2::vector<unsigned char” or “std::__2::basic_string<char”. Quite a few other mDot functions are compiled without problems but do not use string or vector parameters.
I think I might have to move to another IDE (possibly STM cube) which gives me a bit more choice over which compiler is used.
Further research shows that this is not a new problem e.g. reported by [Sachin_Bhat] in 2022 but I see no evidence that Multitech have made any effort to sort it out. Using a different compiler is the only answer.