Summary: | [Crossdev] Pthreads are required to build libgomp at cross-gcc-stage2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | smalcom <smal.root> |
Component: | Current packages | Assignee: | Cross compilation support <cross> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | alexander.puchmayr, correabuscar+gentoo_bugs, herrtimson, petre.rodan, sam, toolchain, zabrinski |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
All related journals
stage 2 build logs emerge info + gcc stage2 build logs |
Description
smalcom
2022-12-28 17:49:58 UTC
Created attachment 845495 [details]
All related journals
If it helps: "crossdev" runs without error using glibc-2.33-r13 (and before). Error "pthreads" occurs first when using glibc-2.34-r10. Created attachment 853482 [details]
stage 2 build logs
Same happened here creating an armv7a cross-compiler gcc-12
Not a solution, but compiling aarch64/glibc with USE=static-libs cured the problem for me. (repeated from https://forums.gentoo.org/viewtopic-t-1157929.html) Just ran into this myself. In my case, the gcc lib that fails to find pthreads is libatomic, but everything else matches what I found in this ticket, including the workaround: adding USE=static-libs to cross-aarch64-unknown-linux-gnueabi/glibc allowed cross-aarch64-unknown-linux-gnueabi/gcc stage2 to build successfully. Worth noting that I had a working cross-compiler before, then didn’t upgrade this box for some 2 years, and after upgrading @world I started running into this error. This would indicate it’s a regression. I tried using gcc-11.3.1_p20230427 (the second-latest stable) as cross-compiler, but that didn’t make a difference; only adding USE=static-libs did. I suspect more and more people will be running into this, as they install or update their working cross-toolchain and find that stage2 builds are broken. Oh, and I did not try downgrading glibc because there’s only one stable version of glibc for arm64, so I didn’t see the point since I wouldn’t care to see a masked package build successfully. Created attachment 864588 [details]
emerge info + gcc stage2 build logs
Indeed, as zabrinski@gmx.de pointed out, adding static-libs to package use helps. In my case this looked like: $ cat /etc/portage/package.use/cross-armv7a cross-armv7a-unknown-linux-gnueabihf/glibc static-libs Note that it has to be the cross compiled glibc and not the host glibc! tried to run crossdev --stable --target aarch64_be-unknown-linux-gnu or emerge -q cross-aarch64_be-unknown-linux-gnu/gcc but it kept failing with checking for __atomic_fetch_op for size 8... yes checking for __atomic_fetch_op for size 16... no checking whether byte ordering is bigendian... yes checking for the word size... 8 configure: error: Pthreads are required to build libatomic make[1]: *** [Makefile:17012: configure-target-libatomic] Error 1 make[1]: Leaving directory '/dev/shm/portage/cross-aarch64_be-unknown-linux-gnu/gcc-13.2.1_p20240113-r1/work/build' none of the magic fixes from the comments above have worked, so I came up with my own, which worked for me: --- 8< -------------- echo '!<arch>' > /usr/aarch64_be-unknown-linux-gnu/usr/lib64/libpthread.a --- >8 -------------- voila. perfection. that file was missing on in my BE toolchain, but present in /usr/aarch64-unknown-linux-gnu (the little endian toolchain). merging the cross gcc now works without problems. should I open a new ticket for my case or is it close enough to this ticket here? my use flags: [ebuild R ] cross-aarch64_be-unknown-linux-gnu/gcc-13.2.1_p20240113-r1:13::crossdev USE="cxx hardened openmp (pie) (ssp) zstd -ada -cet -custom-cflags -d -debug -default-stack-clash-protection -default-znow -doc -fixed-point -fortran -go -graphite -ieee-long-double -jit -libssp -lto -modula2 (-multilib) -nls -objc -objc++ -objc-gc (-pch) -pgo -sanitize -systemtap -test -valgrind -vanilla -vtv" 0 KiB [ebuild R ] cross-aarch64_be-unknown-linux-gnu/glibc-2.38-r9:2.2::crossdev USE="caps crypt (ssp) -audit -cet -compile-locales -custom-cflags -doc -gd -hash-sysv-compat -headers-only -multiarch (-multilib) -multilib-bootstrap -nscd -perl -profile (-selinux) -stack-realign -static-libs -suid -systemd -systemtap -test -vanilla" 0 KiB Surprisingly, the workaround in Comment 9 worked(I had the same compile error). Thank you! # cat /usr/aarch64-unknown-linux-gnu/usr/lib64/libpthread.a !<arch> I didn't try the other workarounds. Used for this: # crossdev --target aarch64-unknown-linux-gnu |