Lib arm linux gnueabihf

How can I resolve this issue: libm.so.6: version `GLIBC_2.29′ not found, C/C++?

Do not make a glibc update. The OS depends heavily on the correct version of glibc and updating it will probably cause problems in many other programs. Use a cross compiler environment with the correct version of glibc instead and link your demo program to the same glibc version that is present on the target.

I used on my Ubuntu OS this version: $ ldd —version ldd (Ubuntu GLIBC 2.31-0ubuntu9.7) 2.31 How can I downgraded it?

For the same reasons that I mentioned above you should neither downgrade glibc on your Ubuntu. You need a seperate cross compiling environment with its own compiler and glibc (and any other libraries you need) that match the versions installed on the target system. What compiler did you use to compile your code?

I’ve used cross gcc compiler $ arm-linux-gnueabi-gcc —version arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

The problem is, that your cross compiler environment includes different glibc and libstdc++ versions than those on the target system. It is probably wise to set up a seperate build machine, that matches the OS of the target (debian 10 buster in your case). You could do this for example in a virtual machine, docker container or chroot environment. In such a build environment, you have best chances, that the cross compiler toolchains contain the right library versions. Alternatively you can compile the code right on the target machine, which is easiest to set up.

4 Answers 4

Modifying talsim’s answer from below to what worked for me.

wget -4c https://ftp.gnu.org/gnu/glibc/glibc-2.29.tar.gz tar -zxvf glibc-2.29.tar.gz cd glibc-2.29 mkdir build_dir cd build_dir sudo ../configure --prefix=/opt/glibc sudo make sudo make install 

I have some error at debian, and solve it via install deb package glibc https://packages.debian.org/buster/amd64/libc6/download

sudo dpkg -i your_package_name 

I ran into this problem trying to run Node.js 20 on a Raspberry Pi that is running Buster. As this and other threads have noted, updating the system libraries is very unwise as the OS depends on specific versions. As I also have Raspberry’s running Bullseye, and Node.js 20 runs on Bullseye, it was easy enough to get various updated libraries to experiment with. I created a subdirectory in my home directory called ~/lib and then issued the command export LD_LIBRARY_PATH=~/lib. By copying various newer libraries from my Bullseye system to my ~/lib directory on the Buster system, I was able to determine that only libm.so.6 and libstdc++.so.6 were the out of date libraries preventing Node.js 20 from running.

So if I want to run Node.js 20, I use a bash script that exports the LD_LIBRARY_PATH variable and then invokes node. For me, it is a good workaround until I migrate this system to Bookworm.

I should note that the older the system is, the harder it will be to catch all the dependencies. Just as test, I booted an SD card with an old Wheezy system on it. I was unable to find any collection of libraries that would allow a relatively recent Node.js release to run. I suspect that if I was trying to get Node.js 20 to run under Stretch, it would probably be even more involved than just two libraries and even that might not work due to the age of the system.

Источник

Arch Linux User Repository

@razykov Hi, according to the naming convention, this package should be the latest version of glibc. If you want to target 2.33, you should create a separate package called «arm-linux-gnueabihf-glibc33».

Arch linux arm already updated glibc to 2.35. The current version cannot compile with the environment since a lot of symbols require 2.34. Causing a lot of undefined reference when compiling:

/usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/lib/libarchive.so: undefined reference to `stat64@GLIBC_2.33' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/lib/libarchive.so: undefined reference to `fstat64@GLIBC_2.33' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `dladdr@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `dlclose@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `fstat@GLIBC_2.33' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/lib/libarchive.so: undefined reference to `fstatat64@GLIBC_2.33' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `dlerror@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_key_create@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_rwlock_unlock@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_setspecific@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/liblzma.so.5: undefined reference to `pthread_join@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_rwlock_destroy@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_rwlock_wrlock@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/lib/libarchive.so: undefined reference to `mknod@GLIBC_2.33' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/lib/libarchive.so: undefined reference to `lstat64@GLIBC_2.33' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `dlsym@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_getspecific@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_key_delete@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_rwlock_init@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/liblzma.so.5: undefined reference to `pthread_condattr_setclock@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `stat@GLIBC_2.33' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `dlopen@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_once@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/libcrypto.so.1.1: undefined reference to `pthread_rwlock_rdlock@GLIBC_2.34' /usr/bin/arm-linux-gnueabihf-ld: /tmp/rpi-root/usr/lib/liblzma.so.5: undefined reference to `pthread_create@GLIBC_2.34' 

razykov commented on 2021-10-12 22:42 (UTC)

@fabian-ang Yeah, it’s obvious But I don’t think it’s worth updating the package right now. Popular target distros not updated yet to 2.34. If I update package right now, it won’t work for anyone. Also I plan to create new package that pinning version 2.33 for users of target distro glibc

fabian-ang commented on 2021-10-11 10:15 (UTC)

This is not a bug or something. It’s actually expected behaviour, as glibc is generally not forward-compatible. So a program that was linked against a newer glibc version is not going to run under an older version

razykov commented on 2021-10-04 18:05 (UTC) (edited on 2021-10-04 18:06 (UTC) by razykov)

Yep. I prepared patch for update PKGBUILD to 2.34. It build the package and compile a ‘hello world’ but I ran into a problem ( version ‘GLIBC_2.34’ not found ) when starting the program on RspberryOS (glibc 2.28 ) and ArchlinuxARM (glibc 2.33 ). Now I uploaded patch on my github (https://github.com/razykov/arm-linux-gnueabihf-glibc). If you have any ideas let me know

fabian-ang commented on 2021-10-04 12:32 (UTC)

Is there any specific reason you don’t update glibc?

staletic commented on 2021-06-02 05:38 (UTC)

Can’t be compiled with the lto option enabled. At least when compiled with stage 2 gcc.

gkatev commented on 2020-09-07 12:08 (UTC) (edited on 2020-09-07 12:09 (UTC) by gkatev)

Thought I would/should mention I came across a problem when compiling this. Specifically:

configure:3675: checking for systemtap static probe support configure:3691: arm-linux-gnueabihf-gcc -c -std=gnu11 -g -O2 conftest.c >&5 conftest.c:13:10: fatal error: sys/sdt.h: No such file or directory #include ^~~~~~~~~~~ compilation terminated. configure:3691: $? = 1 configure: failed program was: | . configure:3699: result: no configure:3705: error: in `/tmp/makepkg/arm-linux-gnueabihf-glibc/src/glibc-build': configure:3707: error: systemtap support needs sys/sdt.h with asm support See `config.log' for more details 

Should the sdt header already be present in the toolchain? I was upgrading from 2.28-5, and, at the time, arm-linux-gnueabihf-gcc was version 8.2.1+20181127-1. Maybe the slightly outdated compiler was the reason (?).

I copied the bundled std-config.h and sdt.h to /usr/arm-linux-gnueabihf/include/sys , and the package compiled successfully. (And installed it manually with pacman —overwrite)

xiretza commented on 2020-05-18 17:08 (UTC) (edited on 2020-05-18 17:13 (UTC) by xiretza)

@tavianator: ah, you’re right! Confirmation bias got the better of me, I was convinced it was DEBUG_CFLAGS that were added, not just the -fdebug-prefix-map . In fact DEBUG_CFLAGS is unset just like CFLAGS by !buildflags , but that extra option is then added in /usr/share/makepkg/buildenv/debugflags.sh regardless of the build flags. In that case, yes, just adding -g -O2 is probably the way to go.

tavianator commented on 2020-05-18 15:57 (UTC)

@xiretza: Interesting. This package needs !buildflags to avoid things like -march=x86-64 . But actually with !buildflags , the DEBUG_CFLAGS don’t get passed either. However, makepkg does add -fdebug-prefix-map=$srcdir=/usr/src/debug to CFLAGS , which causes the problem you describe. Therefore I think the best thing to do is to pass the default flags -g -O2 explicitly.

Copyright © 2004-2023 aurweb Development Team.

AUR packages are user produced content. Any use of the provided files is at your own risk.

Источник

g++ libc.so absolute path cross-compiling error

I am cross-compiling on an ubuntu pc for an arm target using the gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux tools. If place the libc.so from the target in the library search path the linker errors with: cannot find /lib/arm-linux-gnueabihf/libc.so.6 If I remove this libc.so then the linking process finishes with no errors. It seems like there might be a symlink to an absolute path in the libc.so library. Is this why I get the linker error? If yes is there a way to modify the symlink?

1 Answer 1

I had the same problem and mostly solved it.

The problem is, that some so files contain no linkable code, but contain a ld linker script. If this linker script contains absolute references, then the linking will fail.

I write a small perl script, that convert all symbolic links to relative links and also patches the so linker scripts to relative path.

That works by hand quite good, the automated process generates a tar file with perl — without making changes at the raspberry file system.

The tar will be unpacked on the host in the sysroot folder and all links are fixed and all so files are fixed to.

less /lib/arm-linux-gnueabihf/libc.so.6 

/* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-littlearm) GROUP ( /lib/arm-linux-gnueabihf/libc.so.6 /usr/lib/arm-linux-gnueabihf/libc_nonshared.a AS_NEEDED ( /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ) ) 

Just with the first test I found that tar will convert all relative links to absolute ones but if I list the tar file everything is relative correctly.

Источник