Uh oh!
There was an error while loading. Please reload this page.
Fix HAVE_PTHREAD_CONDATTR_SETCLOCK detection on Android - #62978
Conversation
Android puts pthread stuff into libc. Because this wasn't detected, we are using some iOS fallbacks in System.Native. I'm propagating how pthreads are detected in the CoreCLR PAL (that was fixed up for Android in the CoreCLR PAL a couple years ago). Failure to properly detect it here was causing build breaks in CoreCLR on Android (that's how I found this).
ghost
commented
Dec 18, 2021
Tagging subscribers to this area: @mangod9 Issue DetailsThis is my second attempt. The first attempt was #58701 that got rolled back because it broke gcc build (#58744) and I wasn't in a good enough mental state to investigate (and I didn't really need it anymore). I now had a look and the fix was simple enough. Android puts pthread stuff into libc. Because this wasn't detected, we are using some iOS fallbacks in System.Native. I'm propagating how pthreads are detected in the CoreCLR PAL (that was fixed up for Android in the CoreCLR PAL a couple years ago). Failure to properly detect it here was causing build breaks in CoreCLR on Android (that's how I found this).
|
wfurt
commented
Dec 28, 2021
This change broke my build on macOS (found via binary search) I'm not sure why CI builds. |
MichalStrehovsky
commented
Dec 28, 2021
That sounds like PTHREAD_LIBRARY is ending up being empty on your machine. I'm not sure how this change would cause that. This change propagated what was already done in the GC's configuration: runtime/src/coreclr/gc/unix/configure.cmake Lines 89 to 100 in dff742a And PAL's configuration: runtime/src/coreclr/pal/src/configure.cmake Lines 87 to 105 in 72d643d If those are not failing on your box before this pull request, there might be something odd going on somewhere. |
wfurt
commented
Dec 29, 2021
I think it fails to detect the PTHREAD_LIBRARY because of include issue. It may be worth of add fallback error/break...? |
MichalStrehovsky
commented
Dec 29, 2021
That's odd - the GC configuration script doesn't treat warnings as error. This is just a warning. Warnings as errors is a questionable choice done for src/libraries/native. The all-warnings-as-errors is causing other odd effects such as #58746 (comment). |
wfurt
commented
Dec 29, 2021
For now, I just added |
wfurt
commented
Dec 29, 2021
Btw there were 3 places I had to touch. I'm wondering if the GC configuration script does not treat it as error but perhaps other places do...? |
wfurt
commented
Dec 30, 2021
I updated Xcode 11.4 -> 13.2 and everything seems to work again. |
MichalStrehovsky
commented
Dec 31, 2021
Great to hear that! This was a mystery issue... |
This is my second attempt. The first attempt was #58701 that got rolled back because it broke gcc build (#58744) and I wasn't in a good enough mental state to investigate (and I didn't really need it anymore). I now had a look and the fix was simple enough.
Android puts pthread stuff into libc. Because this wasn't detected, we are using some iOS fallbacks in System.Native. I'm propagating how pthreads are detected in the CoreCLR PAL (that was fixed up for Android in the CoreCLR PAL a couple years ago).
Failure to properly detect it here was causing build breaks in CoreCLR on Android (that's how I found this).