From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-26 07:38:47
--- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> on 2/25/02 4:02 PM, Bill Kempf at williamkempf_at_h... wrote:
> > --- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> >> I've seen a lot of messages about using autoconf or jam for
> >> Boost. I wonder if these people are making the issue more
> >> it is. Remember that some of us (like pre-X Mac users) use
> >> Jam, we just resolve the build issues manually. It's not that
> >> 1. Expand the Boost archive somewhere
> >> 2. Have your makefile or project file point to the
> >> directory as part of its search for (system) header files.
> >> 3. For mandatory source files, add those individually to your
> >> or makefile.
> >> 4. There is no step 4....
> >> I don't think there are any mandatory source files that must be
put in a
> >> separate (static or dynamic) library first. I'm not entirely
sure of this,
> >> as the Boost.Threads people always talk about a DLL.
> > On Windows platforms Boost.Threads *requires* (I wish it didn't)
> > special care when building. Specifically, the threadmon stuff
> > be in a DLL. So your simple 4 step process above won't work
> > I also expect that this sort of thing will continue to get more
> > more complicated as we add more and more libraries that depend on
> > specific things.
> Why does it need to be in a separate DLL instead of being linked
> user code? Don't OS callbacks work per function, not per library
*sigh* It's complicated, and very Windows specific, and I've
described it numerous times. I *really* need to get this documented
in a Build Procedures page.
Windows provides no API to clean up thread local data when a thread
ends. Instead, you must use DllMain (or the equivalent DLL entry
point routine), which is called by the OS every time any thread in
the process begins/ends, to provide any cleanup required when a
thread ends. The threadmon code and resulting boost_threadmon.dll
provide a mechanism to "hook" thread destruction and allows the
Boost.Threads thread_specific_ptr<> to properly manage the lifetime
of the thread local data. There's simply no other solution to this
problem on the Win32 platform, and I certainly wish there was. :(
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk