Re: [boost] Boost regression notification (2005-10-10 [RC_1_33_0])

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-10-10 23:48:06

On 10/10/05, Rene Rivera <grafik.list_at_[hidden]> wrote:
>
> Caleb Epstein wrote:
> > On 10/10/05, Douglas Gregor <dgregor_at_[hidden]> wrote:
> >
> >>|spirit|
> >>bug_000008: gcc-3_4_3-sunos
> >>grammar_mt_tests: gcc-3_4_3-sunos
> >>owi_mt_tests: gcc-3_4_3-sunos
> >>scoped_lock_tests: gcc-3_4_3-sunos
> >>scoped_lock_tests_debug: gcc-3_4_3-sunos
> >
> > See:* *http://tinyurl.com/8jg2h
> >
> > These failures all appear to be due to unresolved externals when linking
> > with Boost.Threads (nanosleep, sched_yield). I'm claiming major bjam
> > ignorance, so I need help fixing this: how can I ensure that -lrt is
> > included in the link libraries when these tests are built?
>
> Well there's already handling in gcc-tools.jam to add the -lrt when
> running in SunOS. It tests that uname is of the "SunOS*" form. What does
> uname return on that machine?
>
> Oh, I think I see the problem. The test you pointed to isn't being built
> as multi-threaded. The build requirements for those tests need to have
> "<threading>multi" added so that it links in the thread libraries.
>
> Grr, except it looks like the Spirit tests are already trying to add
> that requirement.

BTW, I committed today a changed to expected-failures-markup.xml that
removed some expected failures for the Boost.Threads gcc-on-sunos case. The
code used to link with -static, which didn't work since there are no static
versions of some libs. But it looks like you or someone else fixed it to
just name archive libraries using fully-qualified paths and now the tests
compile and run OK. This is on the RC_1_33_0 branch.

--
Caleb Epstein
caleb dot epstein at gmail dot com