Arch Linux User Repository

I got this error:

==> Verifying source file signatures with gpg...
    gcc-12.1.0.tar.xz ... Passed
 -> arm-linux-gnueabihf-glibc-headers>=2.33-5 not satisfied, flushing install queue
==> Making package: arm-linux-gnueabihf-gcc-stage2 12.1.0-1 (Thu 27 Oct 2022 12:22:31 PM CEST)
==> Checking runtime dependencies...
==> Missing dependencies:
  -> arm-linux-gnueabihf-glibc-headers>=2.33-5
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.
 -> error making: arm-linux-gnueabihf-gcc-stage2

@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'

@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<2.34

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

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

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

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

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 <sys/sdt.h>
         ^~~~~~~~~~~
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)

@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.

@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.