On 11/10/2014 5:56 PM, Andrew Pinski wrote:
On Sat, Oct 11, 2014 at 9:42 AM, Kwok Cheung Yeung <k...@codesourcery.com>
wrote:
__gthread_active_p() in libgcc checks for thread support by looking for the
presence of a symbol from libpthread. With glibc, it looks for
__pthread_key_create. However, it determines that glibc is being used by
checking for a definition of __GLIBC__, which is also defined by uClibc (in
include/features.h), but it does not export __pthread_key_create, causing
the test to always fail. I've fixed this by extending the test for glibc to
check that __UCLIBC__ is not defined, causing the default pthread_cancel to
be tested with uClibc instead.
Why is __GLIBC__ being defined for uclibc? That seems broken. We
complain about __GNUC__ defined for other compilers besides GCC; we
should do the same for defining __GLIBC__ also.
From the comments in include/features.h:
/* There is an unwholesomely huge amount of code out there that depends
on the
* presence of GNU libc header files. We have GNU libc header files.
So here
* we commit a horrible sin. At this point, we _lie_ and claim to be
GNU libc
* to make things like /usr/include/linux/socket.h and lots of apps
work as
* their developers intended. This is IMHO, pardonable, since these
defines
* are not really intended to check for the presence of a particular
library,
* but rather are used to define an _interface_. */
So it looks like a compatibility hack...
Kwok
