On Mon, Apr 3, 2017 at 6:16 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Apr 1, 2017 4:07 AM, "Yann Ylavic" <ylavic....@gmail.com> wrote: > > On Fri, Mar 31, 2017 at 4:21 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: >> So almost two decades later, this is still odd. >> >> apr.h:#define APR_USE_SHMEM_MMAP_TMP 0 >> apr.h:#define APR_USE_SHMEM_MMAP_SHM 0 >> apr.h:#define APR_USE_SHMEM_MMAP_ZERO 0 >> apr.h:#define APR_USE_SHMEM_SHMGET_ANON 0 >> apr.h:#define APR_USE_SHMEM_SHMGET 1 >> apr.h:#define APR_USE_SHMEM_MMAP_ANON 1 >> apr.h:#define APR_USE_SHMEM_BEOS 0 >> apr.h:#define APR_USE_FLOCK_SERIALIZE 0 >> apr.h:#define APR_USE_SYSVSEM_SERIALIZE 1 >> apr.h:#define APR_USE_POSIXSEM_SERIALIZE 0 >> apr.h:#define APR_USE_FCNTL_SERIALIZE 0 >> apr.h:#define APR_USE_PROC_PTHREAD_SERIALIZE 0 >> apr.h:#define APR_USE_PTHREAD_SERIALIZE 1 > > What's odd? > > > > APR_HAS_ describes support of a feature/mechanism. > > APR_USE_ was an imperitive. The presence, in this case of multiple multiples > indicates broken autoconf logic.
Yes I got this, my point is that there are no duplicates here, one and only one per: - named based SHM => SHMEM_SHMGET, - anonymous SHM => MMAP_ANON, - proc mutex => SYSVSEM_SERIALIZE, - pthread mutex => PTHREAD_SERIALIZE (kind of implicit since all unixes use pthreads, but not to be confused with PROC_PTHREAD_SERIALIZE...).
