I have been tracking down a problem that led me to atomic_count.hpp and atomic_count_sync.hpp. This is on a Sparc Solaris 2.8 machine with gcc 4.1.2. The issue is that since 4.1.2 is greater than 4.1 then atomic_count.hpp decides to use atomic_count_sync.hpp. atomic_count_sync.hpp in turn uses the gcc builtin __sync_* functions. This compiles fine but when I try to link my application I get undefined symbol errors for __sync_fetch_and_add_4 and __sync_val_compare_and_swap_4. According to the gcc documentation on gcc's atomic builtins (see http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html) ... "If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated. The external function will carry the same name as the builtin, with an additional suffix `_n' where n is the size of the data type." ... which makes sense of the link error that I'm seeing. It appears that just checking for the gcc version isn't enough to verify that the atomic builtins will actually work without linking in the support functions. Fortunately for me, gcc 4.2.2 added support for sparc processors. Even so, it might be good to include something about this in the release notes. In fact, since the smart pointer library will use these atomic built-ins it would be good to know what other processors will run into the same problem. Glenn Schrader - MIT Lincoln Lab