Hello to all, I keep on working on a shared memory boost library proposal. I've followed Boost.Build guidelines to write the jam file, and auto_link header, but when writing and executing the jam file I have the following errors (I'm new to jam and dll building, so forgive me if you find any question too simple): 1) DLL-s I wanted to reuse detail::thread::lock class for process shared mutexes in order to follow the same structure as thread::mutex, but when building my library dll-s from boost root using bjam "-sTOOLS=vc-7_1" stage/install the linker complains that it can find thread library dlls (I suppose due to auto_link headers). I don't know if linking a dependant library is needed when building a dll (in my embedded world, i never design dll- s so I don't know that). If the library is needed, should I specify a <library-path> for that in dll building rule? If not needed, do I have to define a symbol to disable auto_link feature for boost::thread in my dll rule? 2) boost::thread config Apart from this, when building static libraries, I can't compile boost::detail::thread::scoped_lock if I use it as main locking scheme for process shared mutexes when building single threaded shared memory static library, since thread headers check for correct multithread configuration (I suppose looking for _MT defines). - - - - - - - - - - - - For the moment I've decided to copy thread scoped_lock to my library changing the namespaces so that I can compile my library and continue integration. I would like to know if it is convenient to reuse thread scoped_locks for process shared mutexes. For a simple proposal that can be easily rejected, I'm not requesting any change, but I would like to point out that maybe scoped_locks should be reused for both thread and process shared mutexes in the future. But my main concern is the linker error when building a dll for a boost library that depends on other boost library. Best regards, Ion Gaztañaga