Limit the pthread_rwlock workaround to glibc. Most libcs seem to be reasonable. Bionic (Android) always makes pthread_rwlock_t. Reportedly, NetBSD does too. Default to assuming libcs are reasonable and treat glibc as the exception. Update-Note: If there are non-glibc libcs with similarly problematic headers, this may break the build. Let us know if it does. Fixed: 482 Change-Id: I63052cad7693d9e28d98775205fe7688e262d88c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51685 Reviewed-by: Adam Langley <agl@google.com>
diff --git a/include/openssl/thread.h b/include/openssl/thread.h index 91706fe..c6e357e 100644 --- a/include/openssl/thread.h +++ b/include/openssl/thread.h
@@ -77,14 +77,13 @@ typedef union crypto_mutex_st { void *handle; } CRYPTO_MUTEX; -#elif defined(__MACH__) && defined(__APPLE__) +#elif !defined(__GLIBC__) typedef pthread_rwlock_t CRYPTO_MUTEX; #else -// It is reasonable to include pthread.h on non-Windows systems, however the -// |pthread_rwlock_t| that we need is hidden under feature flags, and we can't -// ensure that we'll be able to get it. It's statically asserted that this -// structure is large enough to contain a |pthread_rwlock_t| by -// thread_pthread.c. +// On glibc, |pthread_rwlock_t| is hidden under feature flags, and we can't +// ensure that we'll be able to get it from a public header. It's statically +// asserted that this structure is large enough to contain a |pthread_rwlock_t| +// by thread_pthread.c. typedef union crypto_mutex_st { double alignment; uint8_t padding[3*sizeof(int) + 5*sizeof(unsigned) + 16 + 8];