Boost logo

Boost :

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-10-26 10:07:29


About Sunpro 5.3 compilation:

I was able to compile most of boost.function, though sometimes I am
getting weird link errors:

all examples compiled but got unresolved function constructors??
allocator_test compiled, linked produce 4 errors in runtime
def_arg test - the same link errors
function_n_test - passed
function_test - the same link errors
function_test_fail - passed
function_test_fai2 - failed
mixin_test - passed
policy_test - passed

I also was able to compile thread src and test_thread test but can't
link test_thread due to unresolved symbols nanosleep, sched_yield,
clock_gettime - anybody know where are they?

Gennadiy.

--- In boost_at_y..., John Maddock <John_Maddock_at_c...> wrote:
> Bill,
>
> First the good news, the thread lib looks great on linux and on Mac
OS X.
> Unfortunately I'm seeing all kinds of failures on solaris.
>
> First of all, boost.function won't build with sunpro 5.3, I haven't
figured
> out why yet - any sunpro experts out there?
>
> When build with gcc, it all builds fine but I see a bunch of runtime
> errors:
>
> **** test failed: condition.timed_wait(lock, xt) == false, file:
> test/test_thread.cpp, line: 44
>
> **** test failed: condition.timed_wait(lock, xt) == false, file:
> test/test_thread.cpp, line: 44
>
> **** test failed: condition.timed_wait(lock, xt) == false, file:
> test/test_thread.cpp, line: 83
>
> **** test failed: condition.timed_wait(lock, xt) == false, file:
> test/test_thread.cpp, line: 44
>
> **** test failed: condition.timed_wait(lock, xt) == false, file:
> test/test_thread.cpp, line: 83
>
> **** test failed: condition.timed_wait(lock, xt) == false, file:
> test/test_thread.cpp, line: 131
>
> **** test failed: condition.timed_wait(lock, xt) == false, file:
> test/test_thread.cpp, line: 44
> Abort (core dumped)
>
> First the failed tests - I've checked and pthread_cond_timedwait is
> returning zero, even though the condition variable is never
signalled. The
> trouble is if I've read the docs correctly pthread_cond_timedwait
can
> return zero any time it wants to (a spurious wakeup). In effect
the client
> would end up polling the condition until it becomes true.
>
> More to the point, a clever pthreads implementation would be able
to tell
> that the condition variable in the test program could never be
signalled
> (because there are nor other non-blocked threads in the process
that could
> signal it), and therefore either return an error code immediately
or else
> return zero immediately. I've no idea what you do about this
though :-(
>
> Finally there is an abort occurring from an uncaught exception from
>
> boost::recursive_mutex::do_unlock
>
> heres the gdb debug session:
>
> boost::recursive_mutex::do_unlock (this=0xffbef8d8)
> at src/recursive_mutex.cpp:344
> 344 int res = 0;
> (gdb)
> 345 res = pthread_mutex_lock(&m_mutex);
> (gdb)
> 346 assert(res == 0);
> (gdb)
> 348 pthread_t tid = pthread_self();
> (gdb)
> 349 if (m_valid_id && !pthread_equal(m_thread_id, tid))
> (gdb)
> 351 res = pthread_mutex_unlock(&m_mutex);
> (gdb)
> 352 assert(res == 0);
> (gdb)
> 353 throw lock_error();
> (gdb) print tid
> $2 = 1
> (gdb) print m_valid_id
> $3 = true
> (gdb) print m_thread_id
> $4 = 1
>
> which implies that pthread_equal is buggy???
>
> - John Maddock
> http://ourworld.compuserve.com/homepages/john_maddock/


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk