From: David Abrahams (dave_at_[hidden])
Date: 2002-10-04 06:54:55
From: "Alkis Evlogimenos" <alkis_at_[hidden]>
> Hi all,
> I have been running the regression tests of the 1.29 branch as part of
> building boost for use with gcc 2.95.1 and gcc 2.96-112, both with
Which platform? Oh, I see from your error messages it's Linux.
> Because in the ios_state_tests I was getting the following link errors:
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/libgcc.a(_eh.o): In function
> undefined reference to `pthread_key_create'
> I modified tools/build/gcc-stlport-tools.jam as follows:
> diff -r1.6 gcc-stlport-tools.jam
> < flags gcc-stlport FINDLIBS <runtime-link>static/<runtime-build>debug
> stlport_$(GCC_STLPORT_LIB_ID)_stldebug ;
> I am not sure this is an appropriate fix but it prevents the pthread
> link errors (it seems that STLport uses some pthread functions but
> add the pthread relevant code in the static library nor it dynamically
> it to the shared one).
That doesn't seem right. Just from looking at your link errors I can see
that it's libgcc2 which is using pthreads. I'm pretty sure people have been
successfully using this toolset on Linux.
Does this happen with any compilers other than 2.96? I ask because that's
not an official GCC release... though we should probably support it since
RedHat shipped it <grrrr>. Either way, I think you need to do a more
careful analysis of the problem before we try to fix it.
> All tests were run using the above patch. Here are the
> test cases that failed:
> (I put the error line first even though it says "failed above test: ..."
> ***************** failed above test: bind_test ********************
> /n/build/alkise/boost/libs/bind/bind_test.cpp:193: template argument 1 is
> relevant code:
> bind<void>(Y(), i, _1, 9, 4)(k);
> BOOST_TEST( global_result == 4938 );
> This happens in both gcc 2.95.1 and gcc 2.96-112. Is this supposed to
> any of the two compilers?
Suggestion: post a separate message for each of the failing libraries, with
that library's name in the header. That will be more likely to raise the
> Any suggestions on workarounds? I understand that 2.95.1 is a little bit
> prehestoric, but any help is appreciated.
Try the suggestion above.
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk