"Compiler threading support not turned on" error
I'm attempting to use Boost.threads on Mac OS X 10.3 and am getting the error "Compiler threading support is not turned on" when trying to compile. I'm using Xcode, which is Apple's IDE, so I'm not sure what to do when the error text helpfully suggests I set the correct command line option. As far as I know, there's nothing extra that you have to do to enable threading support in the compiler. I've written multi-threaded apps using pthreads and never had to deal with command line options. Any suggestions? Thanks, Glen Simmons
I'm attempting to use Boost.threads on Mac OS X 10.3 and am getting the error "Compiler threading support is not turned on" when trying to compile. I'm using Xcode, which is Apple's IDE, so I'm not sure what to do when the error text helpfully suggests I set the correct command line option. As far as I know, there's nothing extra that you have to do to enable threading support in the compiler. I've written multi-threaded apps using pthreads and never had to deal with command line options. Any suggestions?
It means BOOST_HAS_THREADS is not getting defined by the Boost config system: have you replaced changed this from the defaults at all? I ask because boost/config/compiler/gcc.hpp should definitely be defining that symbol on OS X. John.
On 24 Sep, 2004, at 5:13 AM, John Maddock wrote:
I'm attempting to use Boost.threads on Mac OS X 10.3 and am getting the error "Compiler threading support is not turned on" when trying to compile. I'm using Xcode, which is Apple's IDE, so I'm not sure what to do when the error text helpfully suggests I set the correct command line option. As far as I know, there's nothing extra that you have to do to enable threading support in the compiler. I've written multi-threaded apps using pthreads and never had to deal with command line options. Any suggestions?
It means BOOST_HAS_THREADS is not getting defined by the Boost config system: have you replaced changed this from the defaults at all? I ask because boost/config/compiler/gcc.hpp should definitely be defining that symbol on OS X.
None of the config files was changed initially. I also tried running boost_1_31_0/libs/config/configure and using the user.hpp that it generated. That file has BOOST_HAS_PTHREADS defined, but I get the same result. In re-reading my post, I realize that it may sound like I'm getting this error when trying to build Boost. Not the case, Boost seems to build ok and I get the 2 thread dylibs. It's when trying to use the thread library in my code that I get the above. Am I wrong in assuming that, since I ended up with the 2 thread dylibs, the problem is not in the Boost build process? Thanks Glen
In re-reading my post, I realize that it may sound like I'm getting this error when trying to build Boost. Not the case, Boost seems to build ok and I get the 2 thread dylibs. It's when trying to use the thread library in my code that I get the above. Am I wrong in assuming that, since I ended up with the 2 thread dylibs, the problem is not in the Boost build process?
Correct, as I said you need to figure out why BOOST_HAS_THREADS is not getting defined: as far as I can see gcc.hpp should set it unconditionally for your platform, and as far as I can see the build system doesn't do anything special to the gcc command line either, so I'm mystified frankly, John.
On 25 Sep, 2004, at 7:29 AM, John Maddock wrote:
In re-reading my post, I realize that it may sound like I'm getting this error when trying to build Boost. Not the case, Boost seems to build ok and I get the 2 thread dylibs. It's when trying to use the thread library in my code that I get the above. Am I wrong in assuming that, since I ended up with the 2 thread dylibs, the problem is not in the Boost build process?
Correct, as I said you need to figure out why BOOST_HAS_THREADS is not getting defined: as far as I can see gcc.hpp should set it unconditionally for your platform, and as far as I can see the build system doesn't do anything special to the gcc command line either, so I'm mystified frankly,
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? Glen
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... Thanks, John.
On 28 Sep, 2004, at 4:58 AM, John Maddock wrote:
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. Thanks, Glen
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. -- Matthew Peltzer -- goochrules@gmail.com
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
I had this problem while compiling boost for mingw32 (linux->win32). For unknown reasons (to me), mingw's gcc-3.4.1 doesn't compile by default with threads enabled. This way, libstdc++'s define named _GLIBCXX_HAVE_GTHR_DEFAULT isn't defined. If you look in boost/config/stdlib/libstdcpp3.hpp, you'll see that if this define isn't defined, BOOST_HAS_THREADS doesn't get defined either. This check doesn't exist in boost-1_31, but exists in boost-1_32 (from CVS). So I compiled gcc again using --enable-threads, and suddenly all worked as expected. []'s rod On Thu, Sep 23, 2004 at 11:47:04AM -0500, Glen Simmons wrote:
I'm attempting to use Boost.threads on Mac OS X 10.3 and am getting the error "Compiler threading support is not turned on" when trying to compile. I'm using Xcode, which is Apple's IDE, so I'm not sure what to do when the error text helpfully suggests I set the correct command line option. As far as I know, there's nothing extra that you have to do to enable threading support in the compiler. I've written multi-threaded apps using pthreads and never had to deal with command line options. Any suggestions?
Thanks, Glen Simmons
participants (4)
-
Glen Simmons -
goochrules! -
John Maddock -
Rodolfo Schulz de Lima