I'd file this directly upstream, but mails to the mailing list subscription and bug addresses are bouncing. Build fails on armv5tel at least because: ./libtool --mode=compile --quiet gcc -c -I. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -march=armv5te -mfloat-abi=soft pth_mctx.c pth_mctx.c: In function '__pth_mctx_set': pth_mctx.c:480:2: error: #error "Unsupported Linux (g)libc version and/or platform" make: *** [pth_mctx.lo] Error 1 Let me save you a headache: the (obscure) problem here is that it doesn't like Linux 3.x as a build host. aclocal.m4 does: case $PLATFORM in *-*-linux* ) braindead=no case "x`uname -r`" in changequote(, )dnl x2.[23456789]* ) ;; changequote([, ]) * ) braindead=yes ;; it therefore thinks Linux 3.x is braindead, which is the first issue that leads to the above compile error.
Something about your observation can't be true, because recently, pth has been rebuilt in Rawhide with a Linux kernel 3.1.0-0.rc6.git0.0.fc17: http://koji.fedoraproject.org/koji/buildinfo?buildID=263955 As I don't have access to any ARMv5TE machine, I cannot examine this myself.
I don't think that was built on a Linux 3.1 host. root.log says: DEBUG backend.py:394: kver == 2.6.32-131.2.1.el6.x86_64
And still pth builds fine in F-16 x86_64 here, too: $ uname -r 3.1.0-0.rc9.git0.0.fc16.x86_64
Ah yes. Looking closer, this bug will only affect architectures that do not have the MCSC method. x86/x86_64 has that method, ARM falls back on SJLJ, and it is in the SJLJ code where braindeath occurs :)
Created attachment 591825 [details] fix pth for makecontext-less glibc on Linux 3.x kernels I faced the same problem (pth build breaks with a Linux 3.x kernel and a glibc that lacks makecontext et al) recently in my private distro. I've been trying to submit this fix to pth upstream but my emails seem to end up in /dev/null. If Fedora could carry the fix for the time being that would be great.
Applied in Rawhide.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19