Re: About installation

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 
installing
> >> Boost.  I wonder if these people are making the issue more 
complicated than
> >> it is.  Remember that some of us (like pre-X Mac users) use 
Boost without
> >> Jam, we just resolve the build issues manually.  It's not that 
hard, just:
> >> 
> >> 1.  Expand the Boost archive somewhere
> >> 2.  Have your makefile or project file point to the 
BOOST_ROOT/boost
> >> directory as part of its search for (system) header files.
> >> 3.  For mandatory source files, add those individually to your 
project file
> >> 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 
must
> > be in a DLL.  So your simple 4 step process above won't work 
there.
> > I also expect that this sort of thing will continue to get more 
and
> > more complicated as we add more and more libraries that depend on 
OS
> > specific things.
> [TRUNCATE]
> 
> Why does it need to be in a separate DLL instead of being linked 
with the
> user code?  Don't OS callbacks work per function, not per library 
container?

*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. :(

Bill Kempf