Tested x86_64-pc-linux-gnu, committed.
> On Oct 27, 2020, at 3:23 AM, Jonathan Wakely <jwak...@redhat.com> wrote:
>
> On 26/10/20 14:48 -0700, Thomas Rodgers wrote:
>> +#include <ext/numeric_traits.h>
>> +
>> +#if __has_include(<semaphore.h>)
>> +#define _GLIBCXX_HAVE_POSIX_SEMAPHORE 1
>> +#include <semaphore.h>
>
> It occurs to me now that this check probably isn't robust enough. For
> any POSIX system it's probably safe to assume that <semaphore.h> means
> the POSIX header and so sem_t is available.
>
> But on non-POSIX systems there could be some other, unrelated header
> called <semaphore.h> in the include paths that the user is compiling
> this header with. It's not inconceivable that the user's own project
> or some third party lib could provide a file called semaphore.h, which
> wouldn't define sem_t, sem_init etc.
>
> It's OK for now, but we should revisit this and add an autoconf check
> for sem_init etc. to check at build time whether we've got POSIX
> semaphores available or not.
>
> Please add a "FIXME: replace this with an autoconf check" comment
> here.
>
> OK for trunk with that change, thanks.
>
