Linkage problem with std::string

Status
Not open for further replies.

Atlantisbase

New member
Hello all,

I'm running into a linking problem with some very basic code. I'm using Teensyduino 1.44 and Arduino 1.8.7 on Windows 10.
First the code, this is the simplest program exhibiting the problem.
Code:
#include <string>
using namespace std;

void setup() {
  // put your setup code here, to run once:
  
}

void loop() {
  // put your main code here, to run repeatedly:
  string a("foo");

  if(a == "foo")
  {
    
  }
  else if(a == string("bar"))
  {
    
  }
}

Now the results (full output attached)
Code:
Linking everything together...
"C:\\Program Files (x86)\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax,--defsym=__rtc_localtime=1560079820 "-TC:\\Program Files (x86)\\Arduino\\hardware\\teensy\\avr\\cores\\teensy3/mk20dx256.ld" -lstdc++ -mthumb -mcpu=cortex-m4 -fsingle-precision-constant -o "C:\\Users\\ATLANT~1\\AppData\\Local\\Temp\\arduino_build_389382/linker_error_test.ino.elf" "C:\\Users\\ATLANT~1\\AppData\\Local\\Temp\\arduino_build_389382\\sketch\\linker_error_test.ino.cpp.o" "C:\\Users\\ATLANT~1\\AppData\\Local\\Temp\\arduino_build_389382/core\\core.a" "-LC:\\Users\\ATLANT~1\\AppData\\Local\\Temp\\arduino_build_389382" -larm_cortexM4l_math -lm
C:\Users\ATLANT~1\AppData\Local\Temp\arduino_build_389382\sketch\linker_error_test.ino.cpp.o: In function `void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag)':

c:\program files (x86)\arduino\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\bits/basic_string.tcc:219: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned int&, unsigned int)'

c:\program files (x86)\arduino\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\bits/basic_string.tcc:212: undefined reference to `std::__throw_logic_error(char const*)'

C:\Users\ATLANT~1\AppData\Local\Temp\arduino_build_389382\sketch\linker_error_test.ino.cpp.o: In function `bool std::operator==<char, std::char_traits<char>, std::allocator<char> >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)':

c:\program files (x86)\arduino\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\bits/basic_string.h:5016: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(char const*) const'

collect2.exe: error: ld returned 1 exit status

Error compiling for board Teensy 3.2 / 3.1.

This appears to be a linkage error against the standard library.

Based on this, this, and this I tried adding -D_GLIBCXX_USE_CXX11_ABI=0 to the compiler flags. This produces a different set of undefined references (see attached) and while none of them include the std::__cxx11 prefix, they're still in the standard library.

I tried removing the two libraries that get linked (-larm_cortextM41_math -lm) and nothing changed.

I tried a different board (Teensy 3.6 vs. Teensy 3.1/3.2) and nothing changed.

I made sure I wasn't picking up a library, nope no difference.

For good measure I purged the Arduino install and reinstalled. Nope not that. For the record I also see it on Teensyduino 1.43.

I saw I had some other GCC ARM version installed; got rid of them and no change so it's not picking up the wrong version.

So I'm at a loss. I'm fairly certain I've used std::string in the past so I'm not sure what the problem is.
 

Attachments

  • error_output_full.txt
    12.9 KB · Views: 72
  • error_output_with_glibcxx_flag.txt
    55.5 KB · Views: 68
I had done a search on "__cxx11" and didn't find anything.

So that got one of them but the two std::string references are still missing and I see no good reason why they are missing. The exception handler I can understand being missing as exceptions in an embedded context don't make much sense, but I should not have to provide my own implementation of string comparison or allocation (maybe you could argue about allocation).

As an aside, is this issue of having to implement certain primitive internals yourself documented somewhere (besides a forum post that you don't know exists a priori)? If not there really should be if it's a precondition of using the STL.
 
Status
Not open for further replies.
Back
Top