-
Bug
-
Resolution: Unresolved
-
Important (Ebuild)
-
These will be posted later once I can upload the ffs x86-64bit stage1 tarball for reproducing the error
-
Cannot build ffs Harvester based Funtoo stage2s using metro. This is a blocker bug.
-
Unknown at this time but there is a high probability it is related to the newly Gentoo adapted glib-2.36 ebuild, the new binutils-2.39 ebuild, and also could be something deeper in the new toolchain as part of ffs.
-
Seeding a Harvester 2022-11 FFS stage1 into metro to build a stage2 does not complete at this time
During the development of the next Funtoo toolchain in Harvester 2022-11 a very peculiar configure error is being hit with binutils-2.39_p5:
configure: error: pthread not found
This is a blocker error as this version of binutils cannot build during a ffs based metro stage2 build.
Some additional integration testing and R&D I did around this problem:
I actually built the current Harvester 2022-11 toolchain including glibc-2.36-r6 and bintuils-2.39_p5 using a ffs stage3 Docker container. The configure output for pthread related items is below:
grep -i pthread /var/tmp/binutils-2.39_r5_configure.log checking whether pthreads work with -pthread... checking for vsprintf... none required checking for joinable pthread attribute... Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 checking for setproctitle... PTHREAD_CREATE_JOINABLE checking whether more special flags are required for pthreads... no checking for PTHREAD_PRIO_INHERIT... Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
As you can see the error does not throw in this upgrade ffs Docker container.
For comparison this is the failed configure output of binutils-2.39_p5 during a metro stage2 build that is using a new ffs stage1 container and the new Harvester 2022-11 toolchain:
grep -i pthread temp/build.log checking whether pthreads work with -pthread... no checking whether pthreads work with -pthreads... yes checking for the pthreads library -lpthreads... 8 checking whether pthreads work without any flags... yes checking whether pthreads work with -Kthread... configure: updating cache ./config.cache checking whether pthreads work with -pthread... checking that generated files are newer than configure... Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 checking whether pthreads work with -pthread... no checking whether pthreads work with -pthreads... yes checking for the pthreads library -lpthreads... no checking whether pthreads work with -pthreads... no checking whether pthreads work with -mthreads... no checking whether pthreads work without any flags... done checking for the pthreads library -lpthread... -lfl checking whether pthreads work with -Kthread... no checking whether pthreads work with --thread-safe... no checking whether pthreads work with -pthread... no checking whether pthreads work with -mt... no checking for pthread-config... no checking whether pthreads work with -pthreads... checking whether basename is declared... no checking whether pthreads work with -mthreads... bg da de es fi fr ga id it ja pt_BR ru sr sv tr uk vi zh_CN zh_TW bg da de es fi fr ga id it ja pt_BR ru sr sv tr uk vi zh_CN zh_TW checking for the pthreads library -lpthread... checking for msgfmt... -lfl checking whether pthreads work with --thread-safe... checking lex output file root... lex.yy checking whether pthreads work with -mt... yes checking for pthread-config... no configure: error: pthread not found
libpthread is provided by Glibc and another major version change in this new toolchain is indeed glibc-2.36 as compared to glibc 2.33
Doing some reading out on the interwebs, I found a very interesting change starting in Glibc 2.34: libpthread along with some other Glibc libraries are now directly implemented in libc (very much like musl does) – https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
Also, I looked at the changelogs for GNU binutils here and didn't find much: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_39-branch
Then doing a broader search I found this amazing article by Red Hat literally explaining the whole change around libpthread in glibc 2.34 and onwards: https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread#
So the root cause is undetermined at this point, but it definitely is related to Glibc version 2.36 and the new binutils 2.39 in some unknown way and unique to ffs Harvester stage1s. More testing and updates will be posted in this bug as the RCA is being actively performed.
