Research shows this problem was seen by another person not long ago:
http://lists.uclibc.org/pipermail/uclibc/2008-September/020195.html

Using the new linuxthreads on uClibc-0.9.30, I got the problem mentioned at that address under a PPC64.

if sysdep-cancel.h is misplaced then copying it would theoretically work so here is what I did to _force_ things compile:

# cp libpthread/linuxthreads/sysdeps/unix/sysv/linux/powerpc/powerpc32/* libpthread/linuxthreads/sysdeps/powerpc/powerpc32/

# cp libpthread/linuxthreads/sysdeps/unix/sysv/linux/powerpc/powerpc64/* libpthread/linuxthreads/sysdeps/powerpc/powerpc64/

However, it was still not being included, so I copied the pt-machine.h file and used it as a template to do what it does only for the sysdep-cancel.h:

# cp libpthread/linuxthreads/sysdeps/powerpc/{pt-machine.h,sysdep-cancel.h}

# sed -i -e 's|pt-machine.h|sysdep-cancel.h|g' libpthread/linuxthreads/sysdeps/powerpc/sysdep-cancel.h

This allowed the compiler to continue up to the point where the linker could not find the function called: "__h_errno_location" when linking the object code generated by the file:  libpthread/linuxthreads/sysdeps/pthread/herrno-loc.c

This function seems to already be defined here: libc/misc/internals/__h_errno_location.c

removing the duplicate __h_errno_location from libpthread/linuxthreads/sysdeps/pthread/herrno-loc.c does in fact allow the compilation, building, and installation of uClibc.

Of course, arbitrarily removing code is not a good thing..


The problem is that the sysdep-cancel.h is not being properly pathed/including if it should be included at all;
Following that there seems to be a linker problem with the "__h_errno_location" function in the new pthreads implementation.
However, I am not certain about whether or not the __h_errno_location problem was introduced by my possibly improperly copying of sysdep-cancel.h.


A second issue that I noticed is that the powerpc32 was being used on this powerpc64 system with a native powerpc64 host. I am wondering how to specify powerpc64 under uClibc instead of powerpc32. The fact that it is trying to use 32-bit under the 64-bit native host may be relevant to the primary issue.