Issue with mismatched glibc versions when cross compiling.

[rainbain]

I recently followed the tutorial for building Linux Debian for the De10-Nano and am trying to cross compile a program using CMake to run on it. I am running into a issue where glibc appears to have 2 different and I am unsure how this should be fixed. I am new to cross compiling and linux in general and I am unsure how to set it to the glibc version the device is using or if I should update glibc on the device itself.

The current error I get when running the program on the device: ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libpthread.so.0: version `GLIBC_2.30' not found (required by ./dolphin-emu-nogui) ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.29' not found (required by ./dolphin-emu-nogui) ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./dolphin-emu-nogui) ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.33' not found (required by ./dolphin-emu-nogui)

The CMake tool chain I am using:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)

#set(SYSROOT_PATH /home/rainbain/rootfs)
#set(CMAKE_SYSROOT "${SYSROOT_PATH}")

set(CROSS_COMPILE /home/rainbain/Documents/Flipper/Software/gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf/bin/)

#message(STATUS "ARM GCC TOOLCHAIN Location: ${CROSS_COMPILE}")
#message(STATUS "Root Filesystem:"${SYSROOT_PATH})
set(CMAKE_AR                        ${CROSS_COMPILE}arm-none-linux-gnueabihf-ar${CMAKE_EXECUTABLE_SUFFIX})
set(CMAKE_ASM_COMPILER              ${CROSS_COMPILE}arm-none-linux-gnueabihf-gcc${CMAKE_EXECUTABLE_SUFFIX})
set(CMAKE_C_COMPILER                ${CROSS_COMPILE}arm-none-linux-gnueabihf-gcc${CMAKE_EXECUTABLE_SUFFIX})
set(CMAKE_CXX_COMPILER              ${CROSS_COMPILE}arm-none-linux-gnueabihf-g++${CMAKE_EXECUTABLE_SUFFIX})
set(CMAKE_LINKER                    ${CROSS_COMPILE}arm-none-linux-gnueabihf-ld${CMAKE_EXECUTABLE_SUFFIX})
set(CMAKE_OBJCOPY                   ${CROSS_COMPILE}arm-none-linux-gnueabihf-objcopy${CMAKE_EXECUTABLE_SUFFIX} CACHE INTERNAL "")
set(CMAKE_RANLIB                    ${CROSS_COMPILE}arm-none-linux-gnueabihf-ranlib${CMAKE_EXECUTABLE_SUFFIX} CACHE INTERNAL "")
set(CMAKE_SIZE                      ${CROSS_COMPILE}arm-none-linux-gnueabihf-size${CMAKE_EXECUTABLE_SUFFIX} CACHE INTERNAL "")
set(CMAKE_STRIP                     ${CROSS_COMPILE}arm-none-linux-gnueabihf-strip${CMAKE_EXECUTABLE_SUFFIX} CACHE INTERNAL "")

set(CMAKE_C_FLAGS                   "" CACHE INTERNAL "")
set(CMAKE_CXX_FLAGS                 "${CMAKE_C_FLAGS}" CACHE INTERNAL "")

set(CMAKE_C_FLAGS_DEBUG             "-Os -g" CACHE INTERNAL "")
set(CMAKE_C_FLAGS_RELEASE           "-Os -DNDEBUG" CACHE INTERNAL "")
set(CMAKE_CXX_FLAGS_DEBUG           "${CMAKE_C_FLAGS_DEBUG}" CACHE INTERNAL "")
set(CMAKE_CXX_FLAGS_RELEASE         "${CMAKE_C_FLAGS_RELEASE}" CACHE INTERNAL "")
set(ENABLE_GENERIC)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

I also tried playing around with changing the system root path for cmake and that seemed to be on the right path but it fails being able to find the correct includes and librarys and that is the point I hit a brick wall as to how to fix it from here.

I really thank you for the super well structured tutorial. I been using the De10 Nano for a while and never liked messing with the HIPS system to any amount and this has greatly helped.

[zangman]

I only have a basic understanding of cmake. But at first glance, the path to CROSS_COMPILE appears incorrect to me.

If you see this section, the approach for setting up the variable CROSS_COMPILE is to give the prefix of the compiler, not the path of the bin folder.

Which is why I set up the CROSS_COMPILE as follows:

export CROSS_COMPILE=$DEWD/gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-

Maybe you can modify it and try compiling again?

Another alternative is to just copy the entire source code to your de10-nano and just run the cmake there. Then you don't have to muck around with cross compiling.

[rainbain]

Alright I fixed the CROSS_COMPILE to be that as well as fixing the rest of my toolchain to match that and it compiles but gives the same error on the device.Also tried the new compiler path with setting the root filesystem this time and the CMake test program linked but the build itself was still unable to locate basic libc part.

For now so that I can test the software I been statically linking it tho that should definitely not be considered a final solution to it. Its been very glitching and inconsistency with linking it with this setting as well. Tho for now I am going to develop the software with static linking and then try and compile it on the device itself at some point tho it may prove difficult. My laptop is struggling to compile it all at once with compiler heap size.

A final solution to this issue is definitively a good idea but for now I am going to work with what I have. Been having to do this with other larger parts of this project anyways.

[zangman]

Sorry for the slow reply. I don't have my de10-nano set up right now to be able to help out with this. But at least you are able to make progress which is a good thing. If I may ask, are you trying to compile some readily available package or is it something of your own? If it's the former, maybe you can share the link and I'll try and see if I can help out when I get some time.

[rainbain]

Yes, its dolphin GameCube emulator. Been making some modifications to it to work on hardware emulation. At its current state of it will compile and run on the De10 nano but you can't really test it without a video platform. My modification has its own if you need that. Just have not pushed the changes yet because it is sped across 3 computers.

[zangman]

Sorry - that looks way too complicated for me to be able to help with :). I'll need to start with learning how cmake works first :).

[kirkster96]

In regards to the original error.

./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libpthread.so.0: versionGLIBC_2.30' not found (required by ./dolphin-emu-nogui) ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libm.so.6: version GLIBC_2.29' not found (required by ./dolphin-emu-nogui) ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libstdc++.so.6: versionGLIBCXX_3.4.26' not found (required by ./dolphin-emu-nogui) ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libc.so.6: version GLIBC_2.33' not found (required by ./dolphin-emu-nogui)

It looks like your dolphin-emu-nogui program is searching for a graphics library it can use inside arm-linux. The graphics library may exist on linux, but it may not have been ported to ARM (yet). Keep in mind that ARM is a microcontrol with a Reduced Instruction Set. This does not mean what you are trying to do can't be done, but it will not be easy.

I have some experience working with compiling and using freeglut graphics library, but not for targeting ARM as the platform. Here is a forum post of someone trying to get GLIBC_2.29 on the Raspberry Pi (which is also an ARM processor).

[rainbain]

In regards to the original error.

./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libpthread.so.0: versionGLIBC_2.30' not found (required by ./dolphin-emu-nogui) ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libm.so.6: version GLIBC_2.29' not found (required by ./dolphin-emu-nogui) ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libstdc++.so.6: versionGLIBCXX_3.4.26' not found (required by ./dolphin-emu-nogui) ./dolphin-emu-nogui: /lib/arm-linux-gnueabihf/libc.so.6: version GLIBC_2.33' not found (required by ./dolphin-emu-nogui)

It looks like your dolphin-emu-nogui program is searching for a graphics library it can use inside arm-linux. The graphics library may exist on linux, but it may not have been ported to ARM (yet). Keep in mind that ARM is a microcontrol with a Reduced Instruction Set. This does not mean what you are trying to do can't be done, but it will not be easy.

I have some experience working with compiling and using freeglut graphics library, but not for targeting ARM as the platform. Here is a forum post of someone trying to get GLIBC_2.29 on the Raspberry Pi (which is also an ARM processor).

What library do you think its referencing to cause this? I had disabled all of them except the /dev/fb access including controller library. Anything but basic multithreading and libstd should be removed from the project with it all being on custom hardware. Sorry if I'm not supper up to date on this been working on other parts of the project's DSPs.

[kirkster96]

I agree. It seems to be looking inside a multithreading library for a graphics library. The error message is showing /lib/arm-linux-gnueabihf/libpthread.so.0 and it couldn't find GLIBC_2.30. It looks like its going through a list of all the things it could possible use that might possibly be in there.

I haven't heard of GLIBC before, but im assuming the G stands for graphics. This error message reminds me of a graphics project I did last year. I have a video from last year where I compile .so. libraries from source.

https://youtu.be/XYiwt2NP1KM?t=612 (link includes time stamp)

If you can track down the source, you could try to compile it with the cross compiler. Then add it with your mutlithreading and libstd libraries.

[rainbain]

I agree. It seems to be looking inside a multithreading library for a graphics library. The error message is showing /lib/arm-linux-gnueabihf/libpthread.so.0 and it couldn't find GLIBC_2.30. It looks like its going through a list of all the things it could possible use that might possibly be in there.

I haven't heard of GLIBC before, but im assuming the G stands for graphics. This error message reminds me of a graphics project I did last year. I have a video from last year where I compile .so. libraries from source.

https://youtu.be/XYiwt2NP1KM?t=612 (link includes time stamp)

If you can track down the source, you could try to compile it with the cross compiler. Then add it with your mutlithreading and libstd libraries. Alright I am finally and had some time to asses some if this issue with some of the info I have as well as a few things I have tryed. GLIBC is the GNU foundations C slandered library. Very useful if you wish for your program to do anything because it contains functions like printf() and malloc().

When analyzing the issue it seems to be that the other very common librarys like pthread (POSIX threads) and libstdc++ are all trying to link to different versions of glibc. Now I would normally relate this sort of issue with having precompiled libraries from too many different sources but when checking my toolchain all its libraries are pulled from a copy of the DE10 Nano's rootfs. This leads me to believe the issue may be contain with how the rootfs was created. This will take some more testing, I had used the rootfs created in the linux Debian build not using yocto making me thing there is a possibility of mismatched glibc versions whiten how those where created.

Going agents that theory, if programs using pthread and the other standard library can compile from the system itself, some work I have had good luck with and seen work in the past, it leves me back to believing this is not a issue whiten how the librarys are whiten the rootfs but rather back to how the toolchain gets these librarys from the system.

Most of my toolchain is created and based of how other systems, like the beagle bone black had set theirs up, to do the same thing. I believe the larger part of this issue comes from what library should be sourced from the rootfs and and what should come from the compiler itself, like glibc and crt.

I have tried getting a new rootfs from the operational system while basing all my toolchain and environment of the one made when using the beagle bone black. Still I ether run into a issue with mismatched librarys when running the software or it not finding the library on build.

As always and help is really appreciated in getting cross platform building to work here as the static linking has proven to be quite inefficient and ineffective. I am not a often user of cmake myself and I almost always avoid cross compiling, so if there is anything your assuming I had to of done right feel free to ask the obvious questions as everything is fair game at this point since ive spent so long trying to get it to work.