You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Graham Leggett <mi...@sharp.fm> on 2020/01/01 12:33:13 UTC
Re: svn commit: r1856051 - in /apr/apr/branches/1.7.x: ./ build/
build/apr_threads.m4 configure.in locks/unix/proc_mutex.c
On 22 Mar 2019, at 15:21, ylavic@apache.org wrote:
> Author: ylavic
> Date: Fri Mar 22 13:21:27 2019
> New Revision: 1856051
>
> URL: http://svn.apache.org/viewvc?rev=1856051&view=rev
> Log:
> Merge r1856022 from trunk:
>
> Use proc mutex pthread by default when robust[_np]
>
> On platforms that support pshared and robust pthread mutex, this is usually
> the best interprocess mutex mechanism because it's efficient, posix, not
> limited and not persistent on the system when the program exits (i.e. no need
> to delete it explicitely before leaving, like IPC SysV or files for instance).
>
> Note that on older POSIX systems pthread_mutex_{setrobust,consistent}() funcs
> existed with the non-posix _np() suffix, and we consider them equivalent.
Looks like this has triggered broken builds on openwrt, would it be possible to take a look?
locks/unix/proc_mutex.c: In function 'proc_mutex_choose_method':
locks/unix/proc_mutex.c:1494:28: error: 'mutex_proc_pthread_methods' undeclared (first use in this function); did you mean 'mutex_posixsem_methods'?
new_mutex->meth = &mutex_proc_pthread_methods;
^~~~~~~~~~~~~~~~~~~~~~~~~~
mutex_posixsem_methods
locks/unix/proc_mutex.c:1494:28: note: each undeclared identifier is reported only once for each function it appears in
locks/unix/proc_mutex.c:1496:27: error: 'apr_os_proc_mutex_t {aka struct apr_os_proc_mutex_t}' has no member named 'pthread_interproc'; did you mean 'psem_interproc'?
if (ospmutex->pthread_interproc == NULL) {
^~~~~~~~~~~~~~~~~
psem_interproc
locks/unix/proc_mutex.c:1499:27: error: 'apr_os_proc_mutex_t {aka struct apr_os_proc_mutex_t}' has no member named 'pthread_interproc'; did you mean 'psem_interproc'?
new_mutex->os.pthread_interproc = ospmutex->pthread_interproc;
^~~~~~~~~~~~~~~~~
psem_interproc
locks/unix/proc_mutex.c:1499:57: error: 'apr_os_proc_mutex_t {aka struct apr_os_proc_mutex_t}' has no member named 'pthread_interproc'; did you mean 'psem_interproc'?
new_mutex->os.pthread_interproc = ospmutex->pthread_interproc;
^~~~~~~~~~~~~~~~~
psem_interproc
make[4]: *** [/home/minfrin/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/apr-1.7.0/build/apr_rules.mk:206: locks/unix/proc_mutex.lo] Error 1
make[4]: Leaving directory '/home/minfrin/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/apr-1.7.0'
make[3]: *** [/home/minfrin/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/apr-1.7.0/build/apr_rules.mk:118: all-recursive] Error 1
make[3]: Leaving directory '/home/minfrin/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/apr-1.7.0'
make[2]: *** [Makefile:80: /home/minfrin/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/apr-1.7.0/.built] Error 2
make[2]: Leaving directory '/home/minfrin/src/openwrt/packages-minfrin/libs/apr'
time: package/feeds/packages/apr/compile#17.19#5.56#22.26
make[1]: *** [package/Makefile:113: package/feeds/packages/apr/compile] Error 2
make[1]: Leaving directory '/home/minfrin/src/openwrt/openwrt'
make: *** [/home/minfrin/src/openwrt/openwrt/include/toplevel.mk:218: package/apr/compile] Error 2
Regards,
Graham
—
Re: svn commit: r1856051 - in /apr/apr/branches/1.7.x: ./ build/
build/apr_threads.m4 configure.in locks/unix/proc_mutex.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 03 Jan 2020, at 12:37, Yann Ylavic <yl...@gmail.com> wrote:
>> Looking at the PTHREAD matches in apr.h:
>>
>> #define APR_USE_PROC_PTHREAD_SERIALIZE 1
>> #define APR_HAS_PROC_PTHREAD_SERIALIZE 0
>
> Inconsistent :/
>
> I can think of two ways to fix it:
> 1. don't check for /dev/zero for PROC_PTHREAD capability,
> 2. don't try to use PROC_PTHREAD by default when cross compiling.
>
> We could do #1 if all unixes had /dev/zero, which I'm not sure of.
>
> With #2, the default when cross compiling on linux-like target would
> probably be SYSVSEM, but forcing with "./configure
> apr_lock_method=USE_PROC_PTHREAD_SERIALIZE ..." is still possible.
> Does not look insane or too much to ask, to me...
>
> So attached patch is #2, better ideas?
Getting back to this one - attached patch 2 worked, can confirm it sorted out the problem and APR built successfully.
Regards,
Graham
—
Re: svn commit: r1856051 - in /apr/apr/branches/1.7.x: ./ build/
build/apr_threads.m4 configure.in locks/unix/proc_mutex.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jan 3, 2020 at 1:46 AM Graham Leggett <mi...@sharp.fm> wrote:
>
> On 02 Jan 2020, at 16:16, Yann Ylavic <yl...@gmail.com> wrote:
>
> >> It looks like, in the generated "apr.h",
> >> APR_USE_PROC_PTHREAD_SERIALIZE is set but not
> >> APR_HAS_PROC_PTHREAD_SERIALIZE?
> >
> > This possibly has to do with "/dev/zero" detection from:
> >
> > APR_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED dnl
> > func:pthread_mutexattr_setpshared dnl
> > file:/dev/zero,
> > hasprocpthreadser="1", hasprocpthreadser="0")
> >
> > I'm not sure it can work for cross-compilation, does forcing it with
> > "./configure ... ac_cv_file__dev_zero=yes ..." help?
>
> Working backwards, I tried the ac_cv_file__dev_zero=yes, and it made no difference in this case.
Hmm OK, probably overridden by AC_CHECK_FILE(/dev/zero)...
>
> Right at the bottom, we have:
>
> hasprocpthreadser=‘0'
>
> which means (if I’m reading this correctly) APR_HAS_PROC_PTHREAD_SERIALIZE is not set.
Right, and that's because AC_CHECK_FILE() does not work when cross-compiling.
>
> Looking at the PTHREAD matches in apr.h:
>
> #define APR_USE_PROC_PTHREAD_SERIALIZE 1
> #define APR_HAS_PROC_PTHREAD_SERIALIZE 0
Inconsistent :/
I can think of two ways to fix it:
1. don't check for /dev/zero for PROC_PTHREAD capability,
2. don't try to use PROC_PTHREAD by default when cross compiling.
We could do #1 if all unixes had /dev/zero, which I'm not sure of.
With #2, the default when cross compiling on linux-like target would
probably be SYSVSEM, but forcing with "./configure
apr_lock_method=USE_PROC_PTHREAD_SERIALIZE ..." is still possible.
Does not look insane or too much to ask, to me...
So attached patch is #2, better ideas?
Regards,
Yann.
Re: svn commit: r1856051 - in /apr/apr/branches/1.7.x: ./ build/
build/apr_threads.m4 configure.in locks/unix/proc_mutex.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Jan 2020, at 16:16, Yann Ylavic <yl...@gmail.com> wrote:
>> It looks like, in the generated "apr.h",
>> APR_USE_PROC_PTHREAD_SERIALIZE is set but not
>> APR_HAS_PROC_PTHREAD_SERIALIZE?
>
> This possibly has to do with "/dev/zero" detection from:
>
> APR_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED dnl
> func:pthread_mutexattr_setpshared dnl
> file:/dev/zero,
> hasprocpthreadser="1", hasprocpthreadser="0")
>
> I'm not sure it can work for cross-compilation, does forcing it with
> "./configure ... ac_cv_file__dev_zero=yes ..." help?
Working backwards, I tried the ac_cv_file__dev_zero=yes, and it made no difference in this case.
Possibly because they are setting the following flags explicitly:
CONFIGURE_VARS += \
ac_cv_sizeof_struct_iovec=1 \
ac_cv_struct_rlimit=yes \
ac_cv_func_sem_open=yes \
ac_cv_func_pthread_mutexattr_setpshared=yes \
apr_cv_mutex_robust_shared=yes \
apr_cv_tcp_nodelay_with_cork=yes \
apr_cv_sock_cloexec=yes \
apr_cv_process_shared_works=yes \
apr_cv_mutex_recursive=yes \
apr_cv_epoll_create1=yes \
apr_cv_epoll=yes \
apr_cv_dup3=yes \
apr_cv_accept4=yes
The lines from config.log with pthread in them are as follows:
[minfrin@bob openwrt]$ cat /home/minfrin/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/apr-1.7.0/config.log | grep pthread
configure:19224: checking pthread.h usability
configure:19224: checking pthread.h presence
configure:19224: checking for pthread.h
configure:19272: checking for CFLAGS needed for pthreads
configure:19362: checking for LIBS needed for pthreads
configure:19456: checking for pthread.h
configure:19757: checking whether pthread_getspecific takes two arguments
conftest.c:37:1: error: too many arguments to function 'pthread_getspecific'
pthread_getspecific(key,&tmp);
/home/minfrin/src/openwrt/openwrt/staging_dir/toolchain-mips_24kc_gcc-7.3.0_musl/include/pthread.h:140:7: note: declared here
void *pthread_getspecific(pthread_key_t);
| #include <pthread.h>
| pthread_key_t key;
| pthread_getspecific(key,&tmp);
configure:19802: checking whether pthread_attr_getdetachstate takes one argument
conftest.c:36:1: error: too few arguments to function 'pthread_attr_getdetachstate'
pthread_attr_getdetachstate(attr);
/home/minfrin/src/openwrt/openwrt/staging_dir/toolchain-mips_24kc_gcc-7.3.0_musl/include/pthread.h:150:5: note: declared here
int pthread_attr_getdetachstate(const pthread_attr_t *, int *);
| #include <pthread.h>
| pthread_attr_t *attr;
| pthread_attr_getdetachstate(attr);
configure:19892: checking for pthread_key_delete
configure:19892: checking for pthread_rwlock_init
configure:19892: checking for pthread_attr_setguardsize
configure:19892: checking for pthread_yield
conftest.c:(.text.startup+0x2): undefined reference to `pthread_yield'
| /* Define pthread_yield to an innocuous variant, in case <limits.h> declares pthread_yield.
| #define pthread_yield innocuous_pthread_yield
| which can conflict with char pthread_yield (); below.
| #undef pthread_yield
| char pthread_yield ();
| #if defined __stub_pthread_yield || defined __stub___pthread_yield
| return pthread_yield ();
configure:19903: checking for pthread_rwlock_t
| /* When using the unproven-pthreads package, we need to pull in this
| * on. XXX Should probably be fixed in the unproven-pthreads package.
| #include <pthread.h>
configure:26041: checking for PTHREAD_PROCESS_SHARED in pthread.h
configure:26077: checking for pthread_mutex_timedlock
configure:26077: checking for pthread_mutexattr_setpshared
configure:26516: checking for pthread_condattr_setpshared
configure:26750: result: decision on apr_lock implementation method... pthread pshared mutex
ac_cv_func_pthread_attr_setguardsize=yes
ac_cv_func_pthread_condattr_setpshared=yes
ac_cv_func_pthread_key_delete=yes
ac_cv_func_pthread_mutex_timedlock=yes
ac_cv_func_pthread_mutexattr_setpshared=yes
ac_cv_func_pthread_rwlock_init=yes
ac_cv_func_pthread_yield=no
ac_cv_header_pthread_h=yes
ac_cv_pthread_attr_getdetachstate_one_arg=no
ac_cv_pthread_getspecific_two_args=no
hasprocpthreadser='0'
have_pthread_condattr_setpshared='1'
have_pthread_mutex_timedlock='1'
procpthreadser='1'
pthreadh='1'
pthreadser=‘1
Right at the bottom, we have:
hasprocpthreadser=‘0'
which means (if I’m reading this correctly) APR_HAS_PROC_PTHREAD_SERIALIZE is not set.
Looking at the PTHREAD matches in apr.h:
[minfrin@bob apr-1.7.0]$ cat /home/minfrin/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/apr-1.7.0/include/apr.h | grep PTHREAD
#define APR_HAVE_PTHREAD_H 1
#define APR_USE_PROC_PTHREAD_SERIALIZE 1
#define APR_USE_PTHREAD_SERIALIZE 1
#define APR_HAS_PROC_PTHREAD_SERIALIZE 0
On my Mac, this works:
Little-Net:apr-1.7 minfrin$ cat include/apr.h | grep PTHREAD
#define APR_HAVE_PTHREAD_H 1
#define APR_USE_PROC_PTHREAD_SERIALIZE 0
#define APR_USE_PTHREAD_SERIALIZE 1
#define APR_HAS_PROC_PTHREAD_SERIALIZE 0
Regards,
Graham
—
Re: svn commit: r1856051 - in /apr/apr/branches/1.7.x: ./ build/
build/apr_threads.m4 configure.in locks/unix/proc_mutex.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Jan 2, 2020 at 2:28 PM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Wed, Jan 1, 2020 at 1:33 PM Graham Leggett <mi...@sharp.fm> wrote:
> >
> > Looks like this has triggered broken builds on openwrt, would it be possible to take a look?
>
> It looks like, in the generated "apr.h",
> APR_USE_PROC_PTHREAD_SERIALIZE is set but not
> APR_HAS_PROC_PTHREAD_SERIALIZE?
This possibly has to do with "/dev/zero" detection from:
APR_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED dnl
func:pthread_mutexattr_setpshared dnl
file:/dev/zero,
hasprocpthreadser="1", hasprocpthreadser="0")
I'm not sure it can work for cross-compilation, does forcing it with
"./configure ... ac_cv_file__dev_zero=yes ..." help?
Regards,
Yann.
Re: svn commit: r1856051 - in /apr/apr/branches/1.7.x: ./ build/
build/apr_threads.m4 configure.in locks/unix/proc_mutex.c
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Graham,
On Wed, Jan 1, 2020 at 1:33 PM Graham Leggett <mi...@sharp.fm> wrote:
>
> Looks like this has triggered broken builds on openwrt, would it be possible to take a look?
It looks like, in the generated "apr.h",
APR_USE_PROC_PTHREAD_SERIALIZE is set but not
APR_HAS_PROC_PTHREAD_SERIALIZE?
Could you please provide the "config.log" file?
Regards,
Yann.