Closed ValentiWorkLearning closed 2 years ago
GCC 8.1.0: GLIBCXX_3.4.25, CXXABI_1.3.11
GCC 9.1.0: GLIBCXX_3.4.26, CXXABI_1.3.12
GCC 9.2.0: GLIBCXX_3.4.27, CXXABI_1.3.12
GCC 9.3.0: GLIBCXX_3.4.28, CXXABI_1.3.12
GCC 10.1.0: GLIBCXX_3.4.28, CXXABI_1.3.12
GCC 11.1.0: GLIBCXX_3.4.29, CXXABI_1.3.13
If I'm not mistaking, the cross-compilers above 8.3.0 can't be launched normally in a such environment(or they may produce some hard-to-reproduce cashes)
The maximum available glibcxx under the RPi is GLIBCXX_3.4.25, while the compiled binary requires GLIBCXX_3.4.28.
@ValentiWorkLearning Good finding. Apparently funny thing is that I didn't know till today that GCC on Linux OSes uses patched glibc called libc6
(Glibc (better known as GNU C Library) has a fork for linux which is called libc6. Libc6 is available via apt.).
Currently, Raspbian OS officially provide patched glibc(or libc6) of version 2.28-10+rpi1
which supports GLIBCXX_3.4.25
:
pi@raspberrypi:~ $ strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep GLIBCXX
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_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_DEBUG_MESSAGE_LENGTH
In contrast to this Official Glibc(by GNU) of version 2.28_(also used by our project binaries)_ instead supports GLIBCXX_3.4.28
. I think this project need to build against libc6
source instead of official glibc.
As I know, glibc cannot be built without rebuilding the whole system via buildroot/yocto because of the dependent software. Probably I'm mistaking. I'll try to find more details
As I know, glibc cannot be built without rebuilding the whole system via buildroot/yocto because of the dependent software.
Nah, you don't need whole system while building glibc itself, you just need the kernel header files. But for cross compiling you need complete system sysroot.
@ValentiWorkLearning OK I've found the problem. You need to define linker flags -Wl,-rpath-link
to define exact libs of old glibc while compiling. See this CMAKE file: https://github.com/abhiTronix/raspberry-pi-cross-compilers/wiki/Cross-Compiler-CMake-Usage-Guide-with-rsynced-Raspberry-Pi-32-bit-OS#2-create-picmake-cmake-file
@ValentiWorkLearning OK I've found the problem. You need to define linker flags
-Wl,-rpath-link
to define exact libs of old glibc while compiling. See this CMAKE file: https://github.com/abhiTronix/raspberry-pi-cross-compilers/wiki/Cross-Compiler-CMake-Usage-Guide-with-rsynced-Raspberry-Pi-32-bit-OS#2-create-picmake-cmake-file
This doesn't seem to work for me. I have setup my toolchain.cmake file exactly as you have it wit the -Wl,-rpath- link
as you have it and although I can cross compile for stretch using gcc10 on my host machine, it doesn't run on the target and complains about an incompatible libstdc++ version.
Bullseye works because I have cross compiled the same project as I compiled for stretch above with gcc10 and it works I'm not sure about buster. I will try that next
whats wierd is that i have 2 cmake projects. they both use exactly the same toolchain file and one runs perfectly on the target but the other one complains about the incompatible stdc++ library being the wrong version
I've tried to use GCC10.2 cross-compiler for building Qt following to your guide. Raspberry setup: the latest available Raspberry OS. Host setup: Ubuntu 20.04 with 10.2 cross-compiler.
The building process was completed successfully except a one thing. It seems impossible to launch the compiled binary( I used qopenglwidget from Qt examples) with the 10.2 cross-tools. The maximum available glibcxx under the RPi is
GLIBCXX_3.4.25
, while the compiled binary requiresGLIBCXX_3.4.28
.According to the table here:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
It seems, that the ABI for running applications which were built using GCC 10.2 cross-compiler is not possible.
I guess, it can be handled somehow, but the maximum available version from the system packages is libstdc++-8-dev.