3

I am trying to compile QtWebApp with Qt5.5.1 onto the latest RPI4-Raspbian Buster and I am encountering inexplicable GLIBCXX unresolved symbols

What Works : QtWebApp cross compiled from windows to armhf using qt5.5.1 binaries natively compiled on Raspbian Buster works fine with the following components

  1. Toolchain : raspberry-gcc8.3.0.exe installed on Windows 10.

  2. Qt Binary Libs : Native compiled on RPI4 Raspbian Buster OS and copied over to Windows 10.

  3. Command line : c:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe -std=c++11 -fPIC -I. {ALL QT INCLUDE DIRS} -IC:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/opt/vc/include -g -rdynamic -funwind-tables -Woverflow {ALL QTWEB SOURCE FILES} -LC:/SysGCC/pi4/pi4qt551/lib -lQt5Core -lQt5Gui -lQt5Widgets -lQt5Multimedia -lQt5MultimediaWidgets -lQt5Network -lm -lpthread -o qtweb

This produces an arm executable that worksfine on RPI-4.

What fails

When compiling natively (which is what I want as the development env) on RPI4 the compilation strangely fails with the following error :

/usr/bin/ld: /tmp/ccnnsRCD.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev@@GLIBCXX_3.4.21'

What I have tried (didnt work)

1) Following suggestions from Converting std::__cxx11::string to std::string and passing -D_GLIBCXX_USE_CXX11_ABI=0 it fails with the following error :

/usr/bin/ld: /tmp/ccZfI5co.o: undefined reference to symbol '_ZNSaIcED1Ev@@GLIBCXX_3.4'

where those symbol demangles to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() and std::allocator<char>::~allocator() respectively.

2) I also ran all the combinations WITH/WITHOUT -std=c++11 and D_GLIBCXX_USE_CXX11_ABI=0 and these are the errors 

WITH  -std=c++11, WITHOUT -D_GLIBCXX_USE_CXX11_ABI=0 
/usr/bin/ld: /tmp/ccnnsRCD.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev@@GLIBCXX_3.4.21'

 WITH -std=c++11, WITH -D_GLIBCXX_USE_CXX11_ABI=0 
/usr/bin/ld: /tmp/ccZfI5co.o: undefined reference to symbol '_ZNSaIcED1Ev@@GLIBCXX_3.4'

 WITHOUT -std=c++11, WITH -D_GLIBCXX_USE_CXX11_ABI=0 
/usr/bin/ld: /tmp/cctFncwz.o: undefined reference to symbol '_ZNSaIcED1Ev@@GLIBCXX_3.4'

 WITHOUT -std=c++11, WITHOUT -D_GLIBCXX_USE_CXX11_ABI=0 
/usr/bin/ld: /tmp/cchkJYdO.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev@@GLIBCXX_3.4.21'

3) I also copied the sysroot from the raspberry-gcc8.3.0.exe install on Win10 over to RPi-4 and passed that to gcc as its --sysroot location - which also fails with the ~basic_string() unresolver error. (I dont know how to verify if the --sysroot had any effect though I checked that gcc -v output doesnt have --with_libs in it as suggested in a GCC ignores --sysroot post)

INFO: The command line is exactly the same on the RPI4-Buster other than using gcc and not passing -IC:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/opt/vc/include

Question : How is it that (assuming no glaring compile option mismatch ;) cross compiling with a gcc 8.3 toolchain from windows to arm-linux works but the same code base when compiled natively on raspbian buster with gcc 8.3 fails with what looks like GLIBCXX version mismatch in the Raspbian Buster OS binaries ?

I am stuck on this for 2 days now. Please suggest any other steps I can try here.

sith
  • 447
  • 7
  • 15
  • Have you tried cross-compiling from other Unix-like systems? Have you tried locally-compiling on a Linux system, with gcc 8.3.0 ? – einpoklum Aug 16 '19 at 11:53
  • @einpoklum not tried other unix-like env. Buster is the only linux system I tried locally compiling on. Regardless I am stumped on how an entirely native compile can have GLIBCXX conflicts... I am either being blind to something trivial or its a bug in the newish buster distro... come to think of it I guess I should post this on rpi.org also... – sith Aug 16 '19 at 12:22
  • 1
    Maybe it's a library version mismatch somehow. Could you have more than a single libstdc++ installed? Also - have you tried adding `-lstdc++`? – einpoklum Aug 16 '19 at 12:30
  • @einpoklum ok, I will try `-lstdc++` and post the result. ( while wondering if its not implied by -std=c++11 ...) – sith Aug 16 '19 at 12:41
  • Another thing to do is to example the symbols in your C++ library files, and see whether you have similar symbols in there; if you do, try to figure out what the differences are. – einpoklum Aug 16 '19 at 12:51
  • @einpoklum - thanks for your prompt responses - really appreciate it. I will get home in a couple of hours and post the result. Also I havn't installed any other packages to cause more than one libstdc++ being accessed -unless its in the Buster distro. – sith Aug 16 '19 at 12:56
  • @einpoklum "examine symbols in your C++ library files" - thats what I have been doing most of yesterday - I will repeat it in for the qt551 binaries and post what I find here . should I check any where else? – sith Aug 16 '19 at 13:00
  • Try making your compiler be verbose, to see exactly which files it's using in practice; those are the ones to search. Otherwise use a system-wide `locate` index. – einpoklum Aug 16 '19 at 13:07
  • @einpoklum - amazingly `-lstdc++` resolves both basic_string and std::allocator symbols... Thanks a ton ! Please post this as an answer and I will accept it. phew... – sith Aug 16 '19 at 17:03
  • Just checking... did you invoke GCC using `gcc` or `g++`? – einpoklum Aug 17 '19 at 20:28
  • guilty as charged ;) I used gcc but after just superficial check some time back. see response to @marc glisse below. – sith Aug 18 '19 at 07:52

1 Answers1

3
  • Are you executing the compiler as gcc instead of g++? That would cause this problem. Invoke g++.
  • Otherwise, Try adding -lstdc++ to your link flags.

Explanation:

The symbols are, obviously, from the C++ standard library. Under some circumstances - at the very least, when you invoke GCC using the gcc binary rather than g++ - GCC compiles C++ code, but doesn't automatically link against the GNU C++ standard library. If for some reason this isn't resolved by invoking g++, you could try adding the -lstdc++ flag, which means "link against the library libstdc++.so or libstdc++.a which you should find in the library search path".

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • 1
    Usually, that happens to people who call `gcc` instead of `g++`. – Marc Glisse Aug 17 '19 at 19:58
  • indeed g++ resolves this without -lstdc++... - but I did check sometime back whether g++ linked to gcc as I have seen many times. While it did not, arm-linux-gnueabihf-gcc-8 arm-linux-gnueabihf-g++-8 had identical size and timestamp in /usr/bin. - but just now running a diff reports they are not identical binaries.... well ;) – sith Aug 18 '19 at 07:51
  • 1
    @MarcGlisse: Edited accordingly. – einpoklum Aug 18 '19 at 08:09
  • The same thing has just happened to me when compiling with ```clang```. Adding ```-lstdc++``` to the flags solved the problem. Thanks! – Dominik Mokriš Oct 21 '22 at 17:19