Ah yes, the neverending saga of the SUN C++ compiler, version 5.5 in this particular case. My apologies if this information is already well-known, I have been off the list for a couple of months, but a quick check of the mailing list archive didn't show any discussion regarding this subject. I had been trying to figure out what's breaking the simple shared_ptr to weak_ptr assignments and copies on this particular compiler. The code shown below is based on the code in the above file, around line 260. Anyway, for reference, the following test fails using the default settings for sunpro-tools.jam: weak_ptr<X> wp2 = static_pointer_cast<X>(p5); BOOST_TEST(wp2.use_count() == 1); as the reference count is 2, not 1 as expected. After looking at the source code for static_pointer_cast<> and a bit of experimentation with different types of scoping produced the following code instead: weak_ptr<X> wp2; { wp2 = static_pointer_cast<X>(p5); } BOOST_TEST(wp2.use_count() == 1); Interestingly, this code works as expected - it appears that this particular compiler doesn't clean up the temporary shared_ptr<X> that's being generated inside static_pointer_cast<> until it hits a closing '}'. Digging around the web confirmed that originally the SUN C++ compilers destroyed temporaries as described above and the newer compilers are still backward-compatible. In order to get standard-compliant behaviour one needs to specify -features=tmplife. One updated boost jamfile and the compiler appears to be much happier - all the smart_ptr appear to pass now, apart from shared_ptr_assign_fail.cpp which I assume isn't supposed compile in the first place. A quick test suggests that the 5.3 also supports the above compiler flag so it may be worth including this setting in the sunpro-tools.jam file, however I haven't tested this yet.