From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-29 15:15:06
John Torjo wrote:
> Michael Glassford wrote:
>
>> John Torjo wrote:
>>
>>> Neal D. Becker wrote:
>>>
>>>> I'm very interested in a good (simple) logging library. I haven't
>>>> looked at
>>>
>>>
>>>
>>>
>>> it is simple indeed. Just think that the whole code resides now in
>>> only 3 files!
>>>
>>>> your code yet, but you say win32 only. Do you know what is needed
>>>> to port
>>>> to posix/gcc3 platforms? Is the effort large?
>>>>
>>>
>>> No, the effort is not large. What I'll need to do is port the TSS part -
>>
>>
>>
>> Are you using Boost.Threads tss? Many of its limitations have been
>> addressed in the upcoming Boost release, though unfortunately the
>> cleanup issue in statically linked Win32 builds hasn't been dealt
>> with, yet.
>>
>
> nope. not using Boost.Threads tss yet.
> As I said, I've implemented it Win32 only yet - so I'm using
> TlsAlloc/TlsSlot/etc.
>
> Do you recommend I get the latest boost.thread? By the way, does the
> latest Boost.Thread allow for static linking? If not, I won't use it yet
> - it's really annoying (not having static linking).
This will be in the release notes:
Static-link build option added
The option to link Boost.Threads as a static library has been added back
with some limitations. This feature was originally removed because
boost::thread_specific_ptr required that Boost.Threads be dynamically
linked in order for its cleanup functionality to work on Win32
platforms. Several options are currently being explored to resolve this
issue. In the meantime, the ability to link Boost.Threads statically has
been added back with boost::thread_specific_ptr support removed from the
statically linked version. The decision to add it back was made because
its lack is one of the most frequent complaints about Boost.Threads and
because the other approaches that are being investigated to deal with
boost::thread_specific_ptr cleanup look fairly promising.
Note
Boost.Threads is still dynamically linked by default. In order to force
it to be statically linked, it is necessary to #define
BOOST_THREAD_USE_LIB before any of the Boost.Threads header files are
#included.
Note
If the boost::thread_specific_ptr cleanup issue cannot be resolved by
some other means, it is highly likely that the option to statically link
Boost.Threads will be removed again in a future version of Boost, at
least for Win32 platforms. This is because the
boost::thread_specific_ptr functionality will be increasingly used by
Boost.Threads itself, so that proper cleanup will become essential in
future versions of Boost.Threads.
Mike