Am 18.04.2017 um 00:16 schrieb Yann Ylavic:
Thanks Rainer for the detailed report (as usual).

On Mon, Apr 17, 2017 at 2:01 PM, Rainer Jung <rainer.j...@kippdata.de> wrote:

c) Failure to compile apr on Solaris 8
--------------------------------------

Using gcc 4.1.2 compiling locks/unix/proc_mutex.c:

 In function 'proc_mutex_pthread_create':
607: error: lvalue required as left operand of assignment
 In function 'proc_mutex_pthread_acquire_ex':
711: error: lvalue required as left operand of assignment
790: warning: implicit declaration of function 'pthread_mutex_timedlock'
 In function 'proc_mutex_pthread_release':
868: error: lvalue required as left operand of assignment
 In function 'proc_mutex_pthread_cond_create':
945: error: lvalue required as left operand of assignment

Concerning pthread_mutex_timedlock: that platform has
HAVE_PTHREAD_CONDATTR_SETPSHARED set to 1 but HAVE_PTHREAD_MUTEX_TIMEDLOCK
is not defined (and pthread_mutex_timedlock not available). So
APR_USE_PROC_PTHREAD_MUTEX_COND is defined. So in line 688 we enter the
"#else" branch which ends in line 815. That code includes a call to
pthread_mutex_timedlock.

Concerning the "lvalue required as left operand of assignment" the lines are
always of the form

proc_pthread_mutex_cond_locked(SOME_MUTEX) = SOME_INT;

and proc_pthread_mutex_cond_locked(m) is defined as

((m)->pthread_refcounting ? proc_pthread_cast(m)->cond_locked : -1)

which indeed doesn't look like a good lvalue.

Sorry about that, I thought I had tested the
APR_USE_PROC_PTHREAD_MUTEX_COND case with some #undef's on Linux but
it seems I missed it for my latest changes.

All the above hopefuly fixes with r1791718 and r1791728, both
backported to 1.6.x.

The lvalue problem is gone in 1.6.x head, I can compile also on Solaris 8 (and still on my other test platforms).

Running make check, I get a core dump in testsock.c. In test_addr_copy the initial

        rv = apr_sockaddr_info_get(&sa1, *host, APR_UNSPEC, 80, 0, p);
        APR_ASSERT_SUCCESS(tc, "Problem generating sockaddr", rv);

fails when host == "::1". In the following

        rv = apr_sockaddr_info_copy(&sa2, sa1, p);
        APR_ASSERT_SUCCESS(tc, "Problem copying sockaddr", rv);

sa1 is NULL and the copy results in a segmentation fault.

The copy functionality and the test is new in 1.6.x.

IMHO this is more a test problem and not an impl problem, sa1 being not NULL is probably an expected prerequisite for the copy call.

I'll try to add some proper skip to the test if the apr_sockaddr_info_get() fails.

I haven't yet tracked down, why this call fails for Solaris 8, but I am not too concerned about IPv6 and ancient Solaris 8.

Regards,

Rainer

Reply via email to