I've just gotten a chance to read the page. I won't comment much on the build process, but since your focus was on using Boost.Threads I'll make a few comments there. First, you can run the regression test using Jam instead of manually running gcc. Just cd into the test directory and type your typical Jam command (hint, if you create a batch file to set your environment right the entire command can be just "Jam"). This should build the executable and run it. The benefit to this approach is that it "automagically" locates and uses the DLL. This can be helpful when debugging. However, to use the actual debugger, unless it supports JIT Debugging, you'll have to go back to manually insuring everything is set up for this (i.e. copy the DLL as you did). You asked in your paper why there needs to be a DLL. Unfortunately, this is the only way to clean up thread specific storage on Win32. I'm working on putting all of Boost.Threads in a DLL which will at least be more intuitive for most users. As for the segfault... I've experienced the same problem using gcc. Not being a gcc user I'm finding it difficult to debug to figure out why. If you or anyone else can either give me pointers on debugging for gcc or even just supply the fix I'd be eternally grateful ;). In any event, I'm working on this one. Bill Kempf