* Robust shared mutexes? @ 2016-11-26 21:49 Sebastian Kemper 2016-11-26 22:24 ` Rich Felker 0 siblings, 1 reply; 12+ messages in thread From: Sebastian Kemper @ 2016-11-26 21:49 UTC (permalink / raw) To: musl Hello all, I'm cross-compiling for OpenWRT/LEDE and have this variable apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've searched around but found conflicting infos. One post said there's no shared mutex support in musl and the other said there is. And if there is support for it then I'm not sure how robust it is :D Other variables that I think are set correctly but if you disagreed I'd be happy to hear about: ac_cv_va_copy=yes ac_cv_func_realloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes ac_cv_func_setpgrp_void=yes ac_cv_func_pthread_rwlock_init=yes Please keep me on CC if you reply as I'm not subscribed to this list. Kind regards, Sebastian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-26 21:49 Robust shared mutexes? Sebastian Kemper @ 2016-11-26 22:24 ` Rich Felker 2016-11-26 22:51 ` Sebastian Kemper 0 siblings, 1 reply; 12+ messages in thread From: Rich Felker @ 2016-11-26 22:24 UTC (permalink / raw) To: musl; +Cc: Sebastian Kemper On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote: > Hello all, > > I'm cross-compiling for OpenWRT/LEDE and have this variable > apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've > searched around but found conflicting infos. One post said there's no > shared mutex support in musl Do you have a link for that? If there's incorrect information I'd like to reply and see if it can be corrected. > and the other said there is. And if there > is support for it then I'm not sure how robust it is :D musl fully supports robust mutexes, process-shared or not. They are a requirement for current POSIX. > Other variables that I think are set correctly but if you disagreed I'd > be happy to hear about: > > ac_cv_va_copy=yes Yes. This is true for any conforming C implementation. > ac_cv_func_realloc_0_nonnull=yes > ac_cv_func_malloc_0_nonnull=yes Yes. These are not strict requirements, but if malloc(0) returns a null pointer, behavior of realloc becomes a huge mess. All reasonable implementations should return a unique pointer for each malloc(0) call. > ac_cv_func_setpgrp_void=yes Yes, this is a POSIX requirement. > ac_cv_func_pthread_rwlock_init=yes Yes. So is this. > Please keep me on CC if you reply as I'm not subscribed to this list. OK. Rich ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-26 22:24 ` Rich Felker @ 2016-11-26 22:51 ` Sebastian Kemper 2016-11-26 22:56 ` Rich Felker 0 siblings, 1 reply; 12+ messages in thread From: Sebastian Kemper @ 2016-11-26 22:51 UTC (permalink / raw) To: Rich Felker; +Cc: musl On Sat, Nov 26, 2016 at 05:24:43PM -0500, Rich Felker wrote: > On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote: > > Hello all, > > > > I'm cross-compiling for OpenWRT/LEDE and have this variable > > apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've > > searched around but found conflicting infos. One post said there's no > > shared mutex support in musl > > Do you have a link for that? If there's incorrect information I'd like > to reply and see if it can be corrected. Hello Rich, Thank you very much for the reply! I looked for the link and it turns out it was an error on my part. The post wasn't referring to robust shared mutexes. It was regarding process shared mutexes http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html It says musl doesn't have process shared mutexes so one should set apr_cv_process_shared_works=no. I take it that is correct? Again, thank you for taking the time! Kind regards, Sebastian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-26 22:51 ` Sebastian Kemper @ 2016-11-26 22:56 ` Rich Felker 2016-11-26 23:01 ` Szabolcs Nagy ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Rich Felker @ 2016-11-26 22:56 UTC (permalink / raw) To: Sebastian Kemper; +Cc: musl On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote: > On Sat, Nov 26, 2016 at 05:24:43PM -0500, Rich Felker wrote: > > On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote: > > > Hello all, > > > > > > I'm cross-compiling for OpenWRT/LEDE and have this variable > > > apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've > > > searched around but found conflicting infos. One post said there's no > > > shared mutex support in musl > > > > Do you have a link for that? If there's incorrect information I'd like > > to reply and see if it can be corrected. > > Hello Rich, > > Thank you very much for the reply! > > I looked for the link and it turns out it was an error on my part. The > post wasn't referring to robust shared mutexes. It was regarding process > shared mutexes > > http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html > > It says musl doesn't have process shared mutexes so one should set > apr_cv_process_shared_works=no. I take it that is correct? No, it's incorrect and I have no idea where that idea came from. I'll ask Khem. Rich ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-26 22:56 ` Rich Felker @ 2016-11-26 23:01 ` Szabolcs Nagy 2016-11-27 10:54 ` Sebastian Kemper 2016-11-26 23:02 ` Sebastian Kemper 2016-11-28 21:36 ` Khem Raj 2 siblings, 1 reply; 12+ messages in thread From: Szabolcs Nagy @ 2016-11-26 23:01 UTC (permalink / raw) To: musl; +Cc: Sebastian Kemper * Rich Felker <dalias@libc.org> [2016-11-26 17:56:18 -0500]: > On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote: > > > > http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html > > > > It says musl doesn't have process shared mutexes so one should set > > apr_cv_process_shared_works=no. I take it that is correct? > > No, it's incorrect and I have no idea where that idea came from. I'll > ask Khem. > apr might care about sharing mutexes across i386 vs x86_64 ? that does not work (glibc ditto) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-26 23:01 ` Szabolcs Nagy @ 2016-11-27 10:54 ` Sebastian Kemper 2016-11-27 11:37 ` Szabolcs Nagy 2016-11-27 11:51 ` Alexander Monakov 0 siblings, 2 replies; 12+ messages in thread From: Sebastian Kemper @ 2016-11-27 10:54 UTC (permalink / raw) To: musl; +Cc: Szabolcs Nagy On Sun, Nov 27, 2016 at 12:01:10AM +0100, Szabolcs Nagy wrote: > * Rich Felker <dalias@libc.org> [2016-11-26 17:56:18 -0500]: > > On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote: > > > > > > http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html > > > > > > It says musl doesn't have process shared mutexes so one should set > > > apr_cv_process_shared_works=no. I take it that is correct? > > > > No, it's incorrect and I have no idea where that idea came from. I'll > > ask Khem. > > > > apr might care about sharing mutexes across i386 vs x86_64 ? > > that does not work (glibc ditto) Hello Szabolcs, list, I installed a Gentoo musl-1.1.15 x86_64 chroot on my computer. Then I ran ./configure in apr-1.5.2 in the musl chroot and also outside the chroot in a glibc-2.22 environment. The outcome was the same except for apr_cv_mutex_robust_shared: ac_cv_func_setpgrp_void musl yes glibc yes ac_cv_file__dev_zero musl yes glibc yes apr_cv_tcp_nodelay_with_cork musl yes glibc yes apr_cv_mutex_recursive musl yes glibc yes ac_cv_func_pthread_rwlock_init musl yes glibc yes apr_cv_type_rwlock_t=yes musl yes glibc yes apr_cv_process_shared_works musl yes glibc yes apr_cv_mutex_robust_shared musl no glibc yes I've posted the corresponding part from config.log below. It fails because musl doesn't define PTHREAD_MUTEX_ROBUST_NP (glibc does). And apr uses PTHREAD_MUTEX_ROBUST_NP. It means that I should set apr_cv_mutex_robust_shared=no when cross-compiling this apr, I suppose :) configure:25459: checking for robust cross-process mutex support configure:25500: gcc -o conftest -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE conftest.c -lpthread >&5 conftest.c: In function 'main': conftest.c:197:47: error: 'PTHREAD_MUTEX_ROBUST_NP' undeclared (first use in this function) if (pthread_mutexattr_setrobust_np(&attr, PTHREAD_MUTEX_ROBUST_NP)) ^ conftest.c:197:47: note: each undeclared identifier is reported only once for each function it appears in configure:25500: $? = 1 configure: program exited with status 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define __EXTENSIONS__ 1 | #define _ALL_SOURCE 1 | #define _GNU_SOURCE 1 | #define _POSIX_PTHREAD_SEMANTICS 1 | #define _TANDEM_SOURCE 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | #define HAVE_ATOMIC_BUILTINS 1 | #define HAVE_PTHREAD_H 1 | #define HAVE_PTHREAD_H 1 | #define HAVE_PTHREAD_MUTEX_RECURSIVE 1 | #define HAVE_PTHREAD_KEY_DELETE 1 | #define HAVE_PTHREAD_RWLOCK_INIT 1 | #define HAVE_PTHREAD_ATTR_SETGUARDSIZE 1 | #define HAVE_PTHREAD_RWLOCKS 1 | #define HAVE_SCHED_H 1 | #define HAVE_SCHED_YIELD 1 | #define HAVE_GETHOSTBYNAME_R 1 | #define HAVE_GETHOSTBYADDR_R 1 | #define HAVE_GETSERVBYNAME_R 1 | #define HAVE_SIGSUSPEND 1 | #define HAVE_SIGWAIT 1 | #define HAVE_POLL 1 | #define HAVE_EPOLL 1 | #define HAVE_EPOLL_CREATE1 1 | #define HAVE_DUP3 1 | #define HAVE_ACCEPT4 1 | #define HAVE_SOCK_CLOEXEC 1 | #define HAVE_FDATASYNC 1 | #define HAVE_EPOLL_CREATE1 1 | #define HAVE_DUP3 1 | #define HAVE_ACCEPT4 1 | #define HAVE_SOCK_CLOEXEC 1 | #define HAVE_GETPWNAM_R 1 | #define HAVE_GETPWUID_R 1 | #define HAVE_GETGRNAM_R 1 | #define HAVE_GETGRGID_R 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_MMAN_H 1 | #define HAVE_SYS_IPC_H 1 | #define HAVE_SYS_SHM_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_MMAP 1 | #define HAVE_MUNMAP 1 | #define HAVE_SHM_OPEN 1 | #define HAVE_SHM_UNLINK 1 | #define HAVE_SHMGET 1 | #define HAVE_SHMAT 1 | #define HAVE_SHMDT 1 | #define HAVE_SHMCTL 1 | #define HAVE_MAP_ANON 1 | #define anonymous shared memory allocation method 1 | #define USE_SHMEM_MMAP_ANON 1 | #define namebased memory allocation method 1 | #define USE_SHMEM_SHMGET 1 | #define HAVE_ALLOCA_H 1 | #define HAVE_ALLOCA 1 | #define HAVE_CALLOC 1 | #define HAVE_SETSID 1 | #define HAVE_GETENV 1 | #define HAVE_PUTENV 1 | #define HAVE_SETENV 1 | #define HAVE_UNSETENV 1 | #define HAVE_WRITEV 1 | #define HAVE_GETIFADDRS 1 | #define HAVE_UTIME 1 | #define HAVE_UTIMES 1 | #define HAVE_SETRLIMIT 1 | #define HAVE_GETRLIMIT 1 | #define HAVE_SENDFILE 1 | #define HAVE_SIGACTION 1 | #define HAVE_DECL_SYS_SIGLIST 0 | #define HAVE_FORK 1 | #define HAVE_STRERROR_R 1 | #define STRERROR_R_RC_INT 1 | #define HAVE_MMAP 1 | #define HAVE_MEMMOVE 1 | #define HAVE_GETPASS 1 | #define HAVE_GMTIME_R 1 | #define HAVE_LOCALTIME_R 1 | #define HAVE_MKSTEMP 1 | #define STDC_HEADERS 1 | #define HAVE_CRYPT_H 1 | #define HAVE_CTYPE_H 1 | #define HAVE_DIRENT_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_ERRNO_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_GRP_H 1 | #define HAVE_LIMITS_H 1 | #define HAVE_MALLOC_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_NETDB_H 1 | #define HAVE_POLL_H 1 | #define HAVE_PWD_H 1 | #define HAVE_SEMAPHORE_H 1 | #define HAVE_SIGNAL_H 1 | #define HAVE_STDARG_H 1 | #define HAVE_STDDEF_H 1 | #define HAVE_STDIO_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_TERMIOS_H 1 | #define HAVE_TIME_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_ARPA_INET_H 1 | #define HAVE_NETINET_IN_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_IOCTL_H 1 | #define HAVE_SYS_MMAN_H 1 | #define HAVE_SYS_PARAM_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_SYS_RESOURCE_H 1 | #define HAVE_SYS_SELECT_H 1 | #define HAVE_SYS_SEM_H 1 | #define HAVE_SYS_SENDFILE_H 1 | #define HAVE_SYS_SIGNAL_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_UIO_H 1 | #define HAVE_SYS_UN_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_NETINET_TCP_H 1 | #define SETPGRP_VOID 1 | #define HAVE_SOCKLEN_T 1 | #define SIZEOF_VOIDP 8 | #define SIZEOF_CHAR 1 | #define SIZEOF_INT 4 | #define SIZEOF_LONG 8 | #define SIZEOF_SHORT 2 | #define SIZEOF_LONG_LONG 8 | #define SIZEOF_PID_T 4 | #define SIZEOF_SSIZE_T 8 | #define SIZEOF_SIZE_T 8 | #define SIZEOF_OFF_T 8 | #define SIZEOF_INO_T 8 | #define SIZEOF_STRUCT_IOVEC 16 | #define HAVE_STRNCASECMP 1 | #define HAVE_STRCASECMP 1 | #define HAVE_STRDUP 1 | #define HAVE_STRSTR 1 | #define HAVE_MEMCHR 1 | #define APR_INT64_STRFN strtol | #define APR_OFF_T_STRFN strtol | #define DSO_USE_DLFCN 1 | #define HAVE_WAITPID 1 | #define HAVE_VLA 1 | #define HAVE_SEMGET 1 | #define HAVE_SEMCTL 1 | #define HAVE_FLOCK 1 | #define HAVE_SEMAPHORE_H 1 | #define HAVE_SEM_CLOSE 1 | #define HAVE_SEM_UNLINK 1 | #define HAVE_SEM_POST 1 | #define HAVE_SEM_WAIT 1 | #define HAVE_LOCK_EX 1 | #define HAVE_F_SETLK 1 | #define HAVE_SEM_UNDO 1 | #define HAVE_POLLIN 1 | #define HAVE_PTHREAD_PROCESS_SHARED 1 | #define HAVE_PTHREAD_MUTEXATTR_SETPSHARED 1 | /* end confdefs.h. */ | | #include <sys/types.h> | #include <pthread.h> | #include <stdlib.h> | | int main(int argc, char **argv) | { | pthread_mutex_t mutex; | pthread_mutexattr_t attr; | | if (pthread_mutexattr_init(&attr)) | exit(1); | if (pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED)) | exit(2); | if (pthread_mutexattr_setrobust_np(&attr, PTHREAD_MUTEX_ROBUST_NP)) | exit(3); | if (pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT)) | exit(4); | if (pthread_mutex_init(&mutex, &attr)) | exit(5); | if (pthread_mutexattr_destroy(&attr)) | exit(6); | if (pthread_mutex_destroy(&mutex)) | exit(7); | | exit(0); | } configure:25510: result: no configure:25895: result: decision on apr_lock implementation method... SysV IPC semget() ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-27 10:54 ` Sebastian Kemper @ 2016-11-27 11:37 ` Szabolcs Nagy 2016-11-27 11:51 ` Alexander Monakov 1 sibling, 0 replies; 12+ messages in thread From: Szabolcs Nagy @ 2016-11-27 11:37 UTC (permalink / raw) To: musl; +Cc: Sebastian Kemper * Sebastian Kemper <sebastian_ml@gmx.net> [2016-11-27 11:54:34 +0100]: > On Sun, Nov 27, 2016 at 12:01:10AM +0100, Szabolcs Nagy wrote: > > * Rich Felker <dalias@libc.org> [2016-11-26 17:56:18 -0500]: > > > On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote: > > > > > > > > http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html > > > > > > > > It says musl doesn't have process shared mutexes so one should set > > > > apr_cv_process_shared_works=no. I take it that is correct? > > > > > > No, it's incorrect and I have no idea where that idea came from. I'll > > > ask Khem. > > > > > > > apr might care about sharing mutexes across i386 vs x86_64 ? > > > > that does not work (glibc ditto) > > Hello Szabolcs, list, > > I installed a Gentoo musl-1.1.15 x86_64 chroot on my computer. Then I > ran ./configure in apr-1.5.2 in the musl chroot and also outside the > chroot in a glibc-2.22 environment. > > The outcome was the same except for apr_cv_mutex_robust_shared: > > ac_cv_func_setpgrp_void musl yes glibc yes > ac_cv_file__dev_zero musl yes glibc yes > apr_cv_tcp_nodelay_with_cork musl yes glibc yes > apr_cv_mutex_recursive musl yes glibc yes > ac_cv_func_pthread_rwlock_init musl yes glibc yes > apr_cv_type_rwlock_t=yes musl yes glibc yes > apr_cv_process_shared_works musl yes glibc yes > apr_cv_mutex_robust_shared musl no glibc yes > > I've posted the corresponding part from config.log below. It fails > because musl doesn't define PTHREAD_MUTEX_ROBUST_NP (glibc does). And > apr uses PTHREAD_MUTEX_ROBUST_NP. It means that I should set > apr_cv_mutex_robust_shared=no when cross-compiling this apr, I suppose > :) the standard name is PTHREAD_MUTEX_ROBUST since posix2008, so this is an apr bug. > configure:25459: checking for robust cross-process mutex support > configure:25500: gcc -o conftest -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE conftest.c -lpthread >&5 > conftest.c: In function 'main': > conftest.c:197:47: error: 'PTHREAD_MUTEX_ROBUST_NP' undeclared (first use in this function) > if (pthread_mutexattr_setrobust_np(&attr, PTHREAD_MUTEX_ROBUST_NP)) > ^ i think they should use the standard name and provide their own definition on legacy systems #ifndef PTHREAD_MUTEX_ROBUST #define PTHREAD_MUTEX_ROBUST PTHREAD_MUTEX_ROBUST_NP #endif ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-27 10:54 ` Sebastian Kemper 2016-11-27 11:37 ` Szabolcs Nagy @ 2016-11-27 11:51 ` Alexander Monakov 2016-11-27 16:26 ` Sebastian Kemper 1 sibling, 1 reply; 12+ messages in thread From: Alexander Monakov @ 2016-11-27 11:51 UTC (permalink / raw) To: Sebastian Kemper; +Cc: musl, Szabolcs Nagy On Sun, 27 Nov 2016, Sebastian Kemper wrote: > I've posted the corresponding part from config.log below. It fails > because musl doesn't define PTHREAD_MUTEX_ROBUST_NP (glibc does). And > apr uses PTHREAD_MUTEX_ROBUST_NP. It means that I should set > apr_cv_mutex_robust_shared=no when cross-compiling this apr, I suppose > :) > > configure:25459: checking for robust cross-process mutex support > configure:25500: gcc -o conftest -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE conftest.c -lpthread >&5 > conftest.c: In function 'main': > conftest.c:197:47: error: 'PTHREAD_MUTEX_ROBUST_NP' undeclared (first use in this function) > if (pthread_mutexattr_setrobust_np(&attr, PTHREAD_MUTEX_ROBUST_NP)) This configure check is very old and predates standartization of robust mutexes in POSIX 2008: http://svn.apache.org/viewvc?view=revision&revision=382030 Consequently, APR uses _np interfaces for robust mutexes, so the their uses in locks/unix/proc_mutex.c would need to be fixed together with this configure check. But I don't understand their use of robust mutexes, in that file proc_mutex_proc_pthread_acquire just calls pthread_mutex_consistent_np without any sort of callback or indicating it to the caller via the return value. Alexander ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-27 11:51 ` Alexander Monakov @ 2016-11-27 16:26 ` Sebastian Kemper 0 siblings, 0 replies; 12+ messages in thread From: Sebastian Kemper @ 2016-11-27 16:26 UTC (permalink / raw) To: Alexander Monakov; +Cc: musl, Szabolcs Nagy Hello Szabolcs and Alexander, Thank you very much for your remarks! For now I've set apr_cv_mutex_robust_shared=no in the Makefile and added a comment as to the reason why so this can be revisited later when apr gets an update. Kind regards, Sebastian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-26 22:56 ` Rich Felker 2016-11-26 23:01 ` Szabolcs Nagy @ 2016-11-26 23:02 ` Sebastian Kemper 2016-11-28 21:36 ` Khem Raj 2 siblings, 0 replies; 12+ messages in thread From: Sebastian Kemper @ 2016-11-26 23:02 UTC (permalink / raw) To: Rich Felker; +Cc: musl On Sat, Nov 26, 2016 at 05:56:18PM -0500, Rich Felker wrote: > On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote: > > > > http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html > > > > It says musl doesn't have process shared mutexes so one should set > > apr_cv_process_shared_works=no. I take it that is correct? > > No, it's incorrect and I have no idea where that idea came from. I'll > ask Khem. > > Rich Hello Rich, Super, my problem is solved, then :-) Thanks for clearing that up! Kind regards, Sebastian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-26 22:56 ` Rich Felker 2016-11-26 23:01 ` Szabolcs Nagy 2016-11-26 23:02 ` Sebastian Kemper @ 2016-11-28 21:36 ` Khem Raj 2016-11-28 21:53 ` Rich Felker 2 siblings, 1 reply; 12+ messages in thread From: Khem Raj @ 2016-11-28 21:36 UTC (permalink / raw) To: musl; +Cc: Sebastian Kemper > On Nov 26, 2016, at 2:56 PM, Rich Felker <dalias@libc.org> wrote: > > On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote: >> On Sat, Nov 26, 2016 at 05:24:43PM -0500, Rich Felker wrote: >>> On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote: >>>> Hello all, >>>> >>>> I'm cross-compiling for OpenWRT/LEDE and have this variable >>>> apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've >>>> searched around but found conflicting infos. One post said there's no >>>> shared mutex support in musl >>> >>> Do you have a link for that? If there's incorrect information I'd like >>> to reply and see if it can be corrected. >> >> Hello Rich, >> >> Thank you very much for the reply! >> >> I looked for the link and it turns out it was an error on my part. The >> post wasn't referring to robust shared mutexes. It was regarding process >> shared mutexes >> >> http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html >> >> It says musl doesn't have process shared mutexes so one should set >> apr_cv_process_shared_works=no. I take it that is correct? > > No, it's incorrect and I have no idea where that idea came from. I'll > ask Khem. > IIRC it was not musl but papering over apr specific issue. I never got time to really dig in to root cause it. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Robust shared mutexes? 2016-11-28 21:36 ` Khem Raj @ 2016-11-28 21:53 ` Rich Felker 0 siblings, 0 replies; 12+ messages in thread From: Rich Felker @ 2016-11-28 21:53 UTC (permalink / raw) To: musl On Mon, Nov 28, 2016 at 01:36:50PM -0800, Khem Raj wrote: > > > On Nov 26, 2016, at 2:56 PM, Rich Felker <dalias@libc.org> wrote: > > > > On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote: > >> On Sat, Nov 26, 2016 at 05:24:43PM -0500, Rich Felker wrote: > >>> On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote: > >>>> Hello all, > >>>> > >>>> I'm cross-compiling for OpenWRT/LEDE and have this variable > >>>> apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've > >>>> searched around but found conflicting infos. One post said there's no > >>>> shared mutex support in musl > >>> > >>> Do you have a link for that? If there's incorrect information I'd like > >>> to reply and see if it can be corrected. > >> > >> Hello Rich, > >> > >> Thank you very much for the reply! > >> > >> I looked for the link and it turns out it was an error on my part. The > >> post wasn't referring to robust shared mutexes. It was regarding process > >> shared mutexes > >> > >> http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html > >> > >> It says musl doesn't have process shared mutexes so one should set > >> apr_cv_process_shared_works=no. I take it that is correct? > > > > No, it's incorrect and I have no idea where that idea came from. I'll > > ask Khem. > > > > IIRC it was not musl but papering over apr specific issue. I never got time to really dig in > to root cause it. Indeed, that's what it seems to be here too. They don't support the standard API, only some ancient glibc _NP version of it, and they don't even do anything to handle the case of ownerdied correctly... Rich ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-11-28 21:53 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-26 21:49 Robust shared mutexes? Sebastian Kemper 2016-11-26 22:24 ` Rich Felker 2016-11-26 22:51 ` Sebastian Kemper 2016-11-26 22:56 ` Rich Felker 2016-11-26 23:01 ` Szabolcs Nagy 2016-11-27 10:54 ` Sebastian Kemper 2016-11-27 11:37 ` Szabolcs Nagy 2016-11-27 11:51 ` Alexander Monakov 2016-11-27 16:26 ` Sebastian Kemper 2016-11-26 23:02 ` Sebastian Kemper 2016-11-28 21:36 ` Khem Raj 2016-11-28 21:53 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).