Dave Abrahams wrote:

l@lo wrote:

...

sunpro-Link-action ../../../libs/smart_ptr/test/bin/shared_ptr_alloc_ test.test/sunpro/debug/runtime-link-dynamic/shared_ptr_alloc_test Undefined first referenced symbol in file boost::__RTTI__1nFboostPchecked_deleter4nBZ___ /rest/proj/users/kercsoj/boost/boost_1_30_0/libs/s mart_ptr/test/bin/shared_ptr_alloc_test.test/sunpr o/debug/runtime-link-dynamic/ SunWS_cache/CC_obj__/_iANwWXwaw2nbnjBybyL.o [Hint: static member boost::__RTTI__1nFboostPchecked_deleter4nBZ___ must be defined in the program]

Are you compiling with RTTI off?

I've seen this error as well. The only workaround I know of is to compile using static template instantiation, rather than Sun CC's template repository. bjam -sTOOLS="sunpro" -sBUILD="<cxxflags>-instances=static" It may also be necessary to delete the libs/smart_ptr/test/bin directory, as Sun's compiler still occasionally attempts to link in oudated code from the template repository. This solution has the drawback of increasing code size due to duplicate template definitions, but is the only solution I've found to this problem. I have managed to strip down the offending code to a test case of about 200 lines, but as my company is dragging its feet on a support contract, I haven't been able to submit it as a bug report. That said, the test suite for smart_ptr will still encounter other problems: [ The rest of this post addresses other Sun compiler issues, feel free to skip it if you're not interested. I didn't cross post it, because I wasn't sure if it should go to boost.devel or boost.build. ] * shared_ptr_alloc_test.cpp still triggers "Assertion: (../lnk/init.cc, line 991)," despite Sun's patch report claming this problem fixed in their most recent patch. * shared_ptr_basic_test has 7 use count errors. * shared_ptr_test has 3 use count errors. * weak_ptr_test has 2 use count errors. I've only been able to do a little investigation of the use count errors, but from what I've seen, they occur when the Sun compiler has to create a shared_ptr temporary, and the destructor for the temporary is delayed. I've run shared_ptr_test in purify, and no memory is being leaked, so I infer that the destructor is in fact being called, just not before the use_count test happens: "shared_ptr_basic_test.cpp" // ... // prior to this line, p5 is a shared_ptr<void> with // use_count == 1, weak_count == 1. line 226: weak_ptr<X> wp2 = static_pointer_cast<X>(p5); // static_pointer_cast creates a shared_ptr<X> temporary: // use_count == 2, weak_count == 2. // temporary is passed to weak_ptr<X>'s constructor // use_count == 2, weak_count == 3. // temporary is NOT immediately destructed. line 228: BOOST_TEST(wp3.use_count() == 1); // this test failed // Sometime after this point (possibly as late as the end of the // function scope) the temporary is destructed. This test (and the others like it) seem to assume that the temporary will be immediately destructed after the assignment, although AFAIK that is not required by the language. Sun's compiler seems to favor delayed destruction, although I haven't had the time to trace the debugger and find exactly where it does happen. My tests were run using: $ CC -V CC: Forte Developer 7 C++ 5.4 Patch 111715-06 2003/3/29

Christopher Currie wrote: [...]

This test (and the others like it) seem to assume that the temporary will be immediately destructed after the assignment, although AFAIK that is not required by the language.

It's required; temporaries are destroyed at the end of the full expression. This is either a bug in Sun CC, or the compiler is in cfront/ARM compatible mode.