1

I am trying to cross-compile dlib using Raspberry Pi's toolchain, with the SD card mounted to my linux Host.

After successful build and install, I start my Pi, and run

python -c 'import dlib'

This is the error output:

ImportError: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by dlib/dlib.so)

When I run it on my Raspberrry Pi, this is what I get:

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_DEBUG_MESSAGE_LENGTH

What's going on? How can I fix this? On my Pi, libstdc++is already at its newest version.

Is this an issue with my HOST machine, which as expected, has the GLIBCXX_3.4.22 string.

If possible, can I downgrade libstdc++ on my host machine so that the maximum version it supports is 3.4.20? How?

Host:

OS: Ubuntu 17.04 64-bit (amd64)

Cross-Compilation environment: Official toolchain hosted here: Raspberry Pi Tools

Another thing that might help is that I am mounting the SD card (which contains the Raspbian OS) to my host machine, and then using a cmake toolchain file to set the sysroot to the location of the SD card.

Output of dpkg -l|grep 'gcc.*arm':

abhishek@K  ~/rpi  $ dpkg -l|grep 'gcc.*arm' ii gcc-6-arm-linux-gnueabihf 6.3.0-12ubuntu2cross1 amd64 GNU C compiler ii gcc-6-arm-linux-gnueabihf-base:amd64 6.3.0-12ubuntu2cross1 amd64 GCC, the GNU Compiler Collection (base package) ii gcc-arm-linux-gnueabihf 4:6.3.0-2ubuntu1 amd64 GNU C compiler for the armhf architecture ii libgcc-6-dev-armhf-cross 6.3.0-12ubuntu2cross1 all GCC support library (development files) ii libgcc1-armhf-cross 1:6.3.0-12ubuntu2cross1 all GCC support library

Note: I posted it on the raspberry SE website, but was suggested to move the question.

  • 1
    Your host machine is probably an i386 or amd64 machine. Raspberry Pi is an arm. Thus, the compilation surely doesn't happen against the glibc++ of your host machine. As you write, there is a cross-compilation environment on it, this cross-compilation environtment has its own, arm-based glibc++, and you have to synchronize its version to your raspberry pi's. But you didn't write anything about your cross compilation environment and about your host OS. What is that? The simplest solution would be to downgrade your cross-compilation environment for that. Or you could take the .22 into your pi. – peterh Sep 8 '17 at 16:10
  • 1
    Or you could link the glibc++ statically into your binary, if it is feasible. There are so many possible solutions, I can't even count them! But to decide, which one should I answer you, you should give more info. – peterh Sep 8 '17 at 16:11
  • @peterh Thank you, Sir. I have updated the question. Hope that provides the info required to provide a feasible solution. I can try copying the glibc++ to the Pi. That seems like the easiest option to me. – Abhishek Soni Sep 8 '17 at 16:17
  • Ok, thanks :-) Here lies another important thing: we re good in Linux, but typically not very good in raspberry. The people of the raspberry site, exactly the opposite :-) But there is some cross-section between us. For example, I checked this raspberry pi tools first time in my life. What I see on the spot: it is a 4 year old project, it is unlikely to have such a new library. I downloaded now the libstdc++ in it, and I see that it has symbols only until GLIBCXX_3.4.19 . Anything what you compile with this library, which is reachable on that github link, – peterh Sep 8 '17 at 16:35
  • here, surely shouldn't want a GLIBCXX_3.4.22 symbol. It is possible (but unlikely) that it won't compile with that old glibc++, but it can't await a symbol, whose existence is unknown for him. – peterh Sep 8 '17 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.