Re: [Boost-users] "Compiler threading support not turned on" error

From: Glen Simmons (gsimmons_at_[hidden])
Date: 2004-10-12 08:45:17

On 9 Oct, 2004, at 1:03 PM, goochrules! wrote:

> I think I just ran into the same problem you did.  I'm using
> boost::thread in a .mm file.  Having seen problems with boost
> libraries and Cocoa before, specifically boost::spirit, I did what I
> did then, and moved the #import <Cocoa/Cocoa.h> to after all my
> <boost/...> includes, and the errors went away.
>
> Because of this I suspect there is a greater issue here with the boost
> and Cocoa headers that is not limited to spirit or thread.

 From a later message in this thread:

>>> OK, it turns out that BOOST_HAS_THREADS *was* getting enabled, but 
>>> was later getting disabled in suffix.hpp because BOOST_HAS_PTHREADS 
>>> was not enabled. I believe that it should be enabled by the 
>>> inclusion of posix_features.hpp, but this is not happening because 
>>> of this test in macos.hpp:
>>> #  ifndef TARGET_CARBON
>>> #     include <boost/config/posix_features.hpp>
>>> #  endif
>>> I'm building a Cocoa project in Xcode, which apparently defines 
>>> TARGET_CARBON for me. Why is posix_features.hpp only included if 
>>> TARGET_CARBON is not defined? You can use posix from a carbon target 
>>> just fine. Commenting out the #ifndef so posix_features.hpp is 
>>> included makes it build and work just fine. Is there some reason for 
>>> this that I'm not seeing? Is this a bug?
>>
>> I don't know enough (well anything really!) about MacOS targets, and 
>> what is and is not correct for them, searching the archives it 
>> appears that I added this check after a user request: 
>> http://lists.boost.org/MailArchives/boost-users/msg02664.php.  
>> Obviously we need a better way of doing things, so any suggestions 
>> welcome...
>
> Ahh, that explains it. The problem is that testing for TARGET_CARBON 
> is too broad for the issue that Mr. Thomale was having. I'm sure there 
> are various macros defined by MSL that would be a better check. Or, 
> (yet) another flag to set in user.hpp indicating that the user is 
> using the MSL. Unfortunately, I am not familiar with MSL, so I can't 
> suggest a fix. For now, I've removed the test for TARGET_CARBON, which 
> solves my problem.

As stated above, I commented out the #ifndef TARGET_CARBON (and 
corresponding #endif) in macos.hpp. If you take a look at the message 
referenced above, the check was added in response to a user who was 
having trouble integrating Boost & Metrowerks CodeWarrior. Since I'm 
not using CodeWarrior, I feel safe in removing the check.

HTH,
Glen