Package Details: arm-linux-gnueabihf-glibc 2.33-4

Git Clone URL: (read-only, click to copy)
Package Base: arm-linux-gnueabihf-glibc
Description: GNU C Library (arm-linux-gnueabihf)
Upstream URL:
Licenses: GPL, LGPL
Conflicts: arm-linux-gnueabihf-eglibc, arm-linux-gnueabihf-glibc-headers
Provides: arm-linux-gnueabihf-eglibc, arm-linux-gnueabihf-glibc-headers
Replaces: arm-linux-gnueabihf-glibc-headers
Submitter: tavianator
Maintainer: razykov
Last Packager: razykov
Votes: 36
Popularity: 0.165258
First Submitted: 2015-09-14 15:40 (UTC)
Last Updated: 2021-10-13 01:08 (UTC)

Latest Comments

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

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 ( 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 <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)

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

xiretza commented on 2020-05-18 14:50 (UTC)

Hey! First of all, thanks for packaging, toolchains are always a pain. Unfortunately, this package can't be built with OPTIONS=(debug) set in makepkg.conf:

In file included from <command-line>:
./../include/libc-symbols.h:75:3: error: #error "glibc cannot be compiled without optimization"
   75 | # error "glibc cannot be compiled without optimization"
      |   ^~~~~
Traceback (most recent call last):
  File "../scripts/", line 120, in <module>
  File "../scripts/", line 116, in main
    consts = glibcextract.compute_c_consts(sym_data,
  File "/build/arm-linux-gnueabihf-glibc/src/glibc-2.31/scripts/", line 62, in compute_c_consts
    subprocess.check_call(cmd, shell=True)
  File "/usr/lib/python3.8/", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'arm-linux-gnueabihf-gcc -std=gnu11 -fgnu89-inline  -fdebug-prefix-map=/build/arm-linux-gnueabihf-glibc/src=/usr/src/debug -Wall -Wwrite-strings -Wundef -fmerge-all-constants -frounding-math -fstack-protector-strong -Wstrict-prototypes -Wold-style-definition -fmath-errno     -ftls-model=initial-exec      -I../include -I/build/arm-linux-gnueabihf-glibc/src/glibc-build/csu  -I/build/arm-linux-gnueabihf-glibc/src/glibc-build  -I../sysdeps/unix/sysv/linux/arm/le  -I../sysdeps/unix/sysv/linux/arm  -I../sysdeps/arm/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/arm  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/arm/le/armv6  -I../sysdeps/arm/armv6  -I../sysdeps/arm/le  -I../sysdeps/arm/include -I../sysdeps/arm  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/9.2.0/include -isystem /usr/lib/gcc/arm-linux-gnueabihf/9.2.0/include-fixed -isystem /usr/arm-linux-gnueabihf/include -D_LIBC_REENTRANT -include /build/arm-linux-gnueabihf-glibc/src/glibc-build/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h       -DTOP_NAMESPACE=glibc -DGEN_AS_CONST_HEADERS           -MD -MP -MF /build/arm-linux-gnueabihf-glibc/src/glibc-build/rtld-global-offsets.h.dT           -MT '/build/arm-linux-gnueabihf-glibc/src/glibc-build/rtld-global-offsets.h.d /build/arm-linux-gnueabihf-glibc/src/glibc-build/rtld-global-offsets.h' -S -o /tmp/tmp6fa6v5c2/test.s -x c - < /tmp/tmp6fa6v5c2/test.c' returned non-zero exit status 1.

By default (without debug), CFLAGS is empty/unset thanks to !buildflags. This causes glibc to fall back to a default set of flags, -g -O2 (see Makeconfig:327).

Now, when debug is set, DEBUG_CFLAGS from makepkg.conf get appended to CFLAGS. This happens after !buildflags unsets the variables, which has been determined to be intentional/notabug after bringing it up in #archlinux-pacman. With CFLAGS now set to -g -fvar-tracking-assignments, the glibc build system no longer falls back to its defaults, and since there's no -Ox option set, the build fails (I have not found an explanation why glibc needs optimizations to be on, so that's just how it is).

There are a couple possible solutions for this, but I think the safest way is to follow the example of official PKGBUILDS. The riscv64-linux-gnu-glibc PKGBUILD for example always sets CFLAGS to a fixed value - while this fixes the problem, it's not ideal because it discards the extra flags added from DEBUG_CFLAGS. I think the best solution would be this:

diff --git a/PKGBUILD b/PKGBUILD
index c670646..2f1ec20 100644
@@ -72,13 +72,10 @@ build() {
   echo "sbindir=/bin" >> configparms
   echo "rootsbindir=/bin" >> configparms

-  # remove fortify for building libraries
-  #
-  CFLAGS=${CFLAGS/-fno-plt/}
-  CXXFLAGS=${CXXFLAGS/-fno-plt/}
-  LDFLAGS=${LDFLAGS/,-z,now/}
+  # remove hardening options for building libraries

   export BUILD_CC=gcc
   export CC=${_target}-gcc

In the normal, non-debug case this behaves exactly the same as the riscv64 glibc (and almost the same as before the change, except no -g being passed by default), and with debug, the debug flags are added while still keeping optimization on and hardening disabled.

tavianator commented on 2019-02-05 01:46 (UTC)

@skogsmaskin: You'll have to build that package first (and its dependencies before it, etc.). Check the pinned post on for the correct order.

skogsmaskin commented on 2019-02-03 13:41 (UTC) (edited on 2019-02-03 13:43 (UTC) by skogsmaskin)

Getting this error from the lastest update:

==> Making package: arm-linux-gnueabihf-glibc 2.28-5 (sø. 03. feb. 2019 kl. 14.39 +0100)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
error: target not found: arm-linux-gnueabihf-gcc-stage2>=8.2.1+20181127
==> ERROR: 'pacman' failed to install missing dependencies.