<p dir="ltr"><br>
On Mar 18, 2016 4:38 AM, "Burton, Ross" <<a href="mailto:ross.burton@intel.com">ross.burton@intel.com</a>> wrote:<br>
><br>
><br>
> On 18 March 2016 at 00:22, Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>> wrote:<br>
>>><br>
>>> Which is interesting as building apr-native (so the site files don't get used) for x86-64 gives:<br>
>>><br>
>>> apr_cv_process_shared_works=yes<br>
>>><br>
>>> Can we not go around disabling stuff when it actually does work?<br>
>><br>
>><br>
>> No it really doesnt work. its running a configure time test on your build host ( which I assume is x86_64 mostly now<br>
>> a days) and then deciding that process shared mutexes work, which is not correct. <br>
>><br>
>> If we think that it should work on x86_64 then lets cache the value to ‘yes’ but not leave it<br>
>> at the mercy of configure.<br>
><br>
><br>
> That was my point: the patch was to add works=no to x86-64 target builds, but if I run the same test on x86-64 hardware directly then the result is works=yes.</p>
<p dir="ltr">Actually it depends on libc implementation of process shared mutexes. So glibc for most arches should set it yes. Musl doesnt have it. So that should be no mostly<br>
><br>
> Ross</p>