2

i'm not on here asking to solve a bug or problem , but just to get an understanding about something from those who have more experience.

I bought a BeagleBone Black (Debian installed). I am cross compiling C++ for it on Windows by using gcc-linaro and the make utility that comes with yagarto tools.

All works and executes fine when developing C code with the C compiler.

With C++ however when I build an executable and transfer it to the bone (via WinSCP), I get the following linker error on execution :

"./leds1: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./leds1)"

I'm not asking to solve that issue exactly.

Does it mean that when building on the host, the library path defined on the host is different to that on the bone?

If however I add "-static" to my linker command in my makefile to statically link libraries at compile time on the host, the code then executes on the bone, but not sure if this is the cause of some other issue i'm having.

Is it ok to statically link the libraries in this case? I'm wondering then could the library code which is statically linked be different to the code it would link to on the bone in the case of dynamic linking?

When I do static linking, does it mean there will be no more unresolved linkages whatsoever (every function is implemented) when the executable is built? The linux system() function that I am calling for example is completely built into my executable then?

Many questions sorry, but all relating to the same misunderstanding. Thanks in advance for your knowledge.

Engineer999
  • 3,683
  • 6
  • 33
  • 71
  • It's probably caused by your build system having a too recent version of `libstdc++.so` (probably from GCC 5.1.0 or newer? See https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html). Try to either downgrade your linaro toolchain to match the version of libstdc++ on your target system, copy `libstdc++.so.6` along with the executable onto your board (and use LD_LIBRARY_PATH) or link statically. – Johannes Schaub - litb Jan 14 '18 at 19:40
  • That's the issue more than likely. Is it ok to statically link tho like that instead? It means the code footprint will be much bigger and there will be then duplicate code on my bone device i'd say? Thanks – Engineer999 Jan 14 '18 at 19:55
  • Related: https://stackoverflow.com/questions/8823267/linking-against-older-symbol-version-in-a-so-file – Johannes Schaub - litb Jan 14 '18 at 19:57
  • I would use a more selective approach than `-static`, which I believe would link all libraries statically. IIRC, there's a `-static-libstdc++` aswell, which should fit your case better. – Johannes Schaub - litb Jan 14 '18 at 20:03
  • @JohannesSchaub-litb . I'm checking the makefile that i'm using , it was taken from an online tutorial project, and I notice that I see no path for libraries. How does the makefile know where to find the libraries actually?. I thought library paths must be explicitly entered with -L and -l in a makefile for each one. I'm wondering does the gcc-linaro compiler just look through it's directories by default? – Engineer999 Jan 23 '18 at 11:55
  • you can tell the linked to be verbose about it's output, then it shows where it looks for libraries. Maybe it looks for pre-configured paths, relative to its sysroot ("/" for native compiler, different for cross compilers). Check GCC option "-dumpspecs" for linker command lines that GCC uses and output the linker script (linker option "-verbose"). – Johannes Schaub - litb Jan 23 '18 at 12:47
  • Relevant https://stackoverflow.com/a/18920937/34509 – Johannes Schaub - litb Jan 23 '18 at 13:09

1 Answers1

0

What that error means is simply that a dynamic libstdc++.so.6 was not found on the device. Whether such a library is actually available is something I do not know.

It may well be that static linking is the only configuration that will work for libstdc++. I know it's possible to static link some libraries and dynamically link others but I don't know either gcc or clang well enough to tell you what options would do that.

If you static link and there are no unresolved symbols then yes, your binary is complete.

SoronelHaetir
  • 14,104
  • 1
  • 12
  • 23
  • Ok thanks. If my binary is complete, does that mean that it contains every single implemented function, even the low-level functions from debian that my application needs? – Engineer999 Jan 14 '18 at 19:58