Gentlemen, Seems like we've just cleared up Boost.Thread failures/regressions on all but one required toolset! See http://tinyurl.com/6h56q. Congratulations on the great job to everyone involved. You can probably guess what I'm about to ask -- can we do something about Intel 8.0/Linux failures? Looking at the output below (from http://tinyurl.com/6mnzn), it seems to me that the test was attempted to be linked against *both* GCC and Intel runtimes: /usr/lib/libc.a(strtol.o)(.text+0x50): In function `strtol': ^^^^^^^^^^^^^^^^^^^^^^^^^ : multiple definition of `strtol' /opt/intel_cc_80/lib/libcprts.a(strtol.o)(.text+0xea): first defined here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ld: Warning: size of symbol `strtol' changed from 24 in /opt/intel_cc_80/lib/libcprts.a(strtol.o) to 73 in icc -g -openmp -static -o "../bin/boost/libs/thread/test/test_barrier_lib.test/ intel-8.0-linux/debug/runtime-link-static/threading-multi/test_barrier_lib" -L../bin/boost/libs/thread/build/libboost_thread.a/intel-8.0-linux/debug/runtime-link-static/threading-multi -L../bin/boost/libs/test/build/libboost_unit_test_framework.a/intel-8.0-linux/debug/runtime-link-static/threading-multi "../bin/boost/libs/thread/test/test_barrier_lib.test/intel-8.0-linux/debug/runtime-link-static/threading-multi/test_barrier.o" "../bin/boost/libs/thread/test/test_barrier_lib.test/intel-8.0-linux/debug/runtime-link-static/threading-multi/tss_null.o" ../bin/boost/libs/thread/build/libboost_thread.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_thread-intel80-m t-sd-1_32.a ../bin/boost/libs/test/build/libboost_unit_test_framework.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_unit_ test_framework.a ../bin/boost/libs/thread/build/libboost_thread.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_thread-intel80-m t-sd-1_32.a ../bin/boost/libs/test/build/libboost_unit_test_framework.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_unit_ test_framework.a -lrt Could somebody comment further/take a deeper look at this? -- Aleksey Gurtovoy MetaCommunications Engineering