Compiling glibc 2.38-7 with linux-api-headers 6.4-1 always fails

Hello dear community!

I want to compile glibc from source to apply optimizations -march=native -mtune=native -O3. I know it’s not safe but the failure doesn’t go away even when compiling without any optimizations! And so I am not able to compile myself glibc which is very bad situation to find myself in as a Linux newbie (joke attempted).

Specifically:

FAIL: misc/tst-mount-compile.

So, what I did (and please do ask for more relevant information if necessary) on freshly installed desktop from Manjaro i3 Community Edition with only minor updates/changes (such as linux66, but the failure I remember back at linux61 and is probably older than that):

yay -G glibc to obtain the package.
makepkg -s (even when I don’t change the PKGBUILD to apply the above mentioned optimizations, the result is the same)

I’ve done this both on my desktop and laptop and across many installs, albeit mostly the same, i.e.,

  • Kernel: 6.6.8-2-MANJARO
  • Shell: zsh 5.9
  • WM: i3

Package Versions:

  • glibc 2.38-7
  • linux-api-headers 6.4-1
  • pacman 6.0.2-14
  • yay 12.2.0-1
  • linux66 6.6.8-2
  • linux66-nvidia 545.29.06-27

Test output (last bit of makepkg -s):

XPASS: conform/UNIX98/ndbm.h/linknamespace
XPASS: conform/XOPEN2K/ndbm.h/linknamespace
XPASS: conform/XOPEN2K8/ndbm.h/linknamespace
XPASS: conform/XPG42/ndbm.h/linknamespace
UNSUPPORTED: elf/tst-audit10
UNSUPPORTED: elf/tst-avx512
UNSUPPORTED: elf/tst-cet-legacy-8
UNSUPPORTED: elf/tst-cet-property-2
XPASS: elf/tst-ifunc-isa-1
XPASS: elf/tst-ifunc-isa-1-static
XPASS: elf/tst-ifunc-isa-2
XPASS: elf/tst-ifunc-isa-2-static
UNSUPPORTED: elf/tst-valgrind-smoke
UNSUPPORTED: math/test-double-libmvec-acos-avx512f
UNSUPPORTED: math/test-double-libmvec-acosh-avx512f
UNSUPPORTED: math/test-double-libmvec-asin-avx512f
UNSUPPORTED: math/test-double-libmvec-asinh-avx512f
UNSUPPORTED: math/test-double-libmvec-atan-avx512f
UNSUPPORTED: math/test-double-libmvec-atan2-avx512f
UNSUPPORTED: math/test-double-libmvec-atanh-avx512f
UNSUPPORTED: math/test-double-libmvec-cbrt-avx512f
UNSUPPORTED: math/test-double-libmvec-cos-avx512f
UNSUPPORTED: math/test-double-libmvec-cosh-avx512f
UNSUPPORTED: math/test-double-libmvec-erf-avx512f
UNSUPPORTED: math/test-double-libmvec-erfc-avx512f
UNSUPPORTED: math/test-double-libmvec-exp-avx512f
UNSUPPORTED: math/test-double-libmvec-exp10-avx512f
UNSUPPORTED: math/test-double-libmvec-exp2-avx512f
UNSUPPORTED: math/test-double-libmvec-expm1-avx512f
UNSUPPORTED: math/test-double-libmvec-hypot-avx512f
UNSUPPORTED: math/test-double-libmvec-log-avx512f
UNSUPPORTED: math/test-double-libmvec-log10-avx512f
UNSUPPORTED: math/test-double-libmvec-log1p-avx512f
UNSUPPORTED: math/test-double-libmvec-log2-avx512f
UNSUPPORTED: math/test-double-libmvec-pow-avx512f
UNSUPPORTED: math/test-double-libmvec-sin-avx512f
UNSUPPORTED: math/test-double-libmvec-sincos-avx512f
UNSUPPORTED: math/test-double-libmvec-sinh-avx512f
UNSUPPORTED: math/test-double-libmvec-tan-avx512f
UNSUPPORTED: math/test-double-libmvec-tanh-avx512f
UNSUPPORTED: math/test-float-libmvec-acosf-avx512f
UNSUPPORTED: math/test-float-libmvec-acoshf-avx512f
UNSUPPORTED: math/test-float-libmvec-asinf-avx512f
UNSUPPORTED: math/test-float-libmvec-asinhf-avx512f
UNSUPPORTED: math/test-float-libmvec-atan2f-avx512f
UNSUPPORTED: math/test-float-libmvec-atanf-avx512f
UNSUPPORTED: math/test-float-libmvec-atanhf-avx512f
UNSUPPORTED: math/test-float-libmvec-cbrtf-avx512f
UNSUPPORTED: math/test-float-libmvec-cosf-avx512f
UNSUPPORTED: math/test-float-libmvec-coshf-avx512f
UNSUPPORTED: math/test-float-libmvec-erfcf-avx512f
UNSUPPORTED: math/test-float-libmvec-erff-avx512f
UNSUPPORTED: math/test-float-libmvec-exp10f-avx512f
UNSUPPORTED: math/test-float-libmvec-exp2f-avx512f
UNSUPPORTED: math/test-float-libmvec-expf-avx512f
UNSUPPORTED: math/test-float-libmvec-expm1f-avx512f
UNSUPPORTED: math/test-float-libmvec-hypotf-avx512f
UNSUPPORTED: math/test-float-libmvec-log10f-avx512f
UNSUPPORTED: math/test-float-libmvec-log1pf-avx512f
UNSUPPORTED: math/test-float-libmvec-log2f-avx512f
UNSUPPORTED: math/test-float-libmvec-logf-avx512f
UNSUPPORTED: math/test-float-libmvec-powf-avx512f
UNSUPPORTED: math/test-float-libmvec-sincosf-avx512f
UNSUPPORTED: math/test-float-libmvec-sinf-avx512f
UNSUPPORTED: math/test-float-libmvec-sinhf-avx512f
UNSUPPORTED: math/test-float-libmvec-tanf-avx512f
UNSUPPORTED: math/test-float-libmvec-tanhf-avx512f
UNSUPPORTED: misc/tst-adjtimex
UNSUPPORTED: misc/tst-clock_adjtime
FAIL: misc/tst-mount-compile
UNSUPPORTED: misc/tst-ntp_adjtime
UNSUPPORTED: nptl/test-cond-printers
UNSUPPORTED: nptl/test-condattr-printers
UNSUPPORTED: nptl/test-mutex-printers
UNSUPPORTED: nptl/test-mutexattr-printers
UNSUPPORTED: nptl/test-rwlock-printers
UNSUPPORTED: nptl/test-rwlockattr-printers
UNSUPPORTED: nptl/tst-pthread-gdb-attach
UNSUPPORTED: nptl/tst-pthread-gdb-attach-static
UNSUPPORTED: posix/tst-cet-vfork-1
UNSUPPORTED: string/tst-memchr-rtm
UNSUPPORTED: string/tst-memcmp-rtm
UNSUPPORTED: string/tst-memmove-rtm
UNSUPPORTED: string/tst-memrchr-rtm
UNSUPPORTED: string/tst-memset-rtm
UNSUPPORTED: string/tst-strcasecmp-rtm
UNSUPPORTED: string/tst-strchr-rtm
UNSUPPORTED: string/tst-strcmp-rtm
UNSUPPORTED: string/tst-strcpy-rtm
UNSUPPORTED: string/tst-strlen-rtm
UNSUPPORTED: string/tst-strncasecmp-rtm
UNSUPPORTED: string/tst-strncmp-rtm
UNSUPPORTED: string/tst-strrchr-rtm
UNSUPPORTED: string/tst-wcscmp-rtm
UNSUPPORTED: string/tst-wcsncmp-rtm
UNSUPPORTED: time/tst-settimeofday
Summary of test results:
      1 FAIL
   5154 PASS
     87 UNSUPPORTED
     12 XFAIL
      8 XPASS
make[1]: *** [Makefile:660: tests] Error 1
make[1]: Leaving directory '/home/bitwise/Downloads/glibc/src/glibc'
make: *** [Makefile:9: check] Error 2
==> ERROR: A failure occurred in check().
    Aborting...

Lastly, Happy New Year:-)
Hopefully, you can help me compile glibc on Manjaro, I feel like I am just overlooking something obvious, however I feel like this should work out of the box as it’s quite common thing to do I’d assume.

Perhaps use the upstream pkgbuild

Perhaps use the upstream pkgbuild

Isn’t cloning the main branch exactly the same as doing yay -G glibc ? It certainly seems to me like it’s the same, including the PKGBUILD.

I don’t use yay - so I wouldn’t know.

EDIT:
→ testing
→ wait for evaluation
→ no issues

Final result

 $ yay -G --repo glibc
 $ cd glibc
 $ makepkg
[...]
make[1]: Leaving directory '/home/fh/glibc/src/glibc'
==> Tidying install...
  -> Removing empty directories...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "lib32-glibc"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Starting package_glibc-locales()...
Mode:                     real
Method:                   sha256
Files:                    5880
Linked:                   3131 files
Compared:                 0 xattrs
Compared:                 33999 files
Saved:                    724,53 MiB
Duration:                 0.536984 seconds
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "glibc-locales"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.

Based on this it is likely a - for your system - local issue

If you’re building a critical system component like glibc, use the native tools. Ditch that POS yay.

May I ask you for your versions of the packages I mentioned in the original post (and perhaps other related that I shall check) ?

Because I have almost clean install of Manjaro i3 Community edition and it fails, both on my new Desktop, old Desktop and Laptop and it’s pretty invariant to package changes.

So I see it’s my local issue but I can’t seem to figure out where the issue is. Any hints would be greatly appreciated.

You are aware of the branch structure?

There is a slight possibility it is branch related if you are on stable as my system is on unstable.

Other than that I have the same package versions.

Well, that might be the difference. Any way to test this hypothesis ?

And if it turns out to be the issue for stable, is there any hope of it being “fixed” anytime soon ?

You could switch to unstable and run a full system sync - then rebuild.

I don’t think it has bearing - just giving you the benefit of the doubt - that’s all

Tried switching, did full system sync and nothing has changed (so switching back to stable).

Well, mystery. No idea what else should I try. Also, I’ve found this collectd issue that might or might not be relevant. The last comment especially points to some interesting ideas.

Do you happen to have any suggestions, like perhaps some packages / configs that might be relevant ?

No - I run a default Manjaro system on unstable branch and my .makepkg.conf is currently default

A relevant snippet

 $ cat ~/.makepkg.conf
[...]
#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
#CPPFLAGS=""
# CFLAGS="-march=native -O2 -pipe -fno-plt -fexceptions"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
        -fstack-clash-protection"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
LTOFLAGS="-flto=auto"
RUSTFLAGS="-C opt-level=2 -C target-cpu=native"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j$(($(nproc)+1))"
#-- Debugging flags
DEBUG_CFLAGS="-g"
DEBUG_CXXFLAGS="$DEBUG_CFLAGS"
#DEBUG_RUSTFLAGS="-C debuginfo=2"
[...]

Additionally, build it in a clean chroot

1 Like

And so it turned out to be combination of me modifying the PKGBUILD badly and even when not modifying it, having wrong ~/.makepkg.conf.

So thank you very much for you time & support, it was indeed mistake at my side.

And thank you for that clean chroot tip as it will surely come in handy sooner rather than later when I go on tinkering with my OS more and more.

Thanks, Manjaro Community

2 Likes

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.