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];