No thread safe libraries built for Darwin when using release 1.33.1?
Hi All, This has been discussed before, but I can't find an answer, so here is another bjam build question. When I build the Boost libraries using the VC8 toolset on the PC, I create thread safe (-mt) versions of the libraries. When I build the Boost libraries on Darwin, there are never any thread safe library versions built, even if I specify "-sBUILD=<threading>multi" on the bjam command line. I have found threads that discuss use of the thread safe version of the regex lib, so I know that it exists and gets built on some platform(s). Why are there no thread safe libraries built for the Darwin toolset? On the surface, this seems like a bug, but I figure there must be some reasonable explanation. (Oh, please, let there be a reasonable explanation! :-) Regards, Rush
Rush Manbert wrote:
Why are there no thread safe libraries built for the Darwin toolset?
Unfortunately... I have no clue why you don't get the multi-thread libs. They did get generated, and tested, for the release. For example the thread libs http://engineering.meta-comm.com/boost-regression/1_33_1/developer/thread_re.... -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Rush Manbert wrote:
Why are there no thread safe libraries built for the Darwin toolset?
Unfortunately... I have no clue why you don't get the multi-thread libs. They did get generated, and tested, for the release. For example the thread libs http://engineering.meta-comm.com/boost-regression/1_33_1/developer/thread_re....
Thanks for the reply. I have poked around a little bit more. By placing #warnings in config/compiler/gcc.hpp and in config/suffix.hpp (which appears to be the only place that BOOST_HAS_THREADS is undefined) I know that if I run the default bjam with the Darwin toolset, then BOOST_HAS_THREADS is defined for every file that is compiled. Does this mean that all of the multi-threading support is enabled in every library? If so, then something still seems wrong, but at least I am building multi-thread libraries.
At 5:15 PM -0700 8/23/06, Rush Manbert wrote:
Rene Rivera wrote:
Rush Manbert wrote:
Why are there no thread safe libraries built for the Darwin toolset?
Unfortunately... I have no clue why you don't get the multi-thread libs. They did get generated, and tested, for the release. For example the thread libs
http://engineering.meta-comm.com/boost-regression/1_33_1/developer/thread_re....
Thanks for the reply. I have poked around a little bit more. By placing #warnings in config/compiler/gcc.hpp and in config/suffix.hpp (which appears to be the only place that BOOST_HAS_THREADS is undefined) I know that if I run the default bjam with the Darwin toolset, then BOOST_HAS_THREADS is defined for every file that is compiled. Does this mean that all of the multi-threading support is enabled in every library? If so, then something still seems wrong, but at least I am building multi-thread libraries.
I haven't used MacOSX extensively for development, but it appears that it *only* supports multi-threaded compilation. For example, the version of gcc that Apple provides doesn't accept the -pthread option; it's always turned on and I don't know of a way to turn it off if one wanted to. It isn't clear whether you are using bare darwin, or darwin on MacOSX, and I don't know if that distinction actually matters for this.
Kim Barrett wrote:
At 5:15 PM -0700 8/23/06, Rush Manbert wrote:
Rene Rivera wrote:
Rush Manbert wrote:
Why are there no thread safe libraries built for the Darwin toolset?
Unfortunately... I have no clue why you don't get the multi-thread libs. They did get generated, and tested, for the release. For example the thread libs
http://engineering.meta-comm.com/boost-regression/1_33_1/developer/thread_re....
Thanks for the reply. I have poked around a little bit more. By placing #warnings in config/compiler/gcc.hpp and in config/suffix.hpp (which appears to be the only place that BOOST_HAS_THREADS is undefined) I know that if I run the default bjam with the Darwin toolset, then BOOST_HAS_THREADS is defined for every file that is compiled. Does this mean that all of the multi-threading support is enabled in every library? If so, then something still seems wrong, but at least I am building multi-thread libraries.
I haven't used MacOSX extensively for development, but it appears that it *only* supports multi-threaded compilation. For example, the version of gcc that Apple provides doesn't accept the -pthread option; it's always turned on and I don't know of a way to turn it off if one wanted to. It isn't clear whether you are using bare darwin, or darwin on MacOSX, and I don't know if that distinction actually matters for this.
It's MacOSX 10.4.7. All I want are multi-threaded libraries, but I also build other third party libraries from source and all of those packages produce both variants on MacOSX. (Or at least they produce libraries with the appropriate names. Maybe the single-thread versions are really multi-thread and they're lying with the names. I hadn't considered that possibility.) It certainly *appears* that I'm building multi-thread libraries, despite the names not including the "-mt", but I was hoping that one of the developer gurus could confirm that this is true as long as BOOST_HAS_THREADS is defined for all the compiles in the build. If that's true, then I'll drop the subject, and maybe resurrect it if 1.34 appears to do the same thing. - Rush
participants (3)
-
Kim Barrett -
Rene Rivera -
Rush Manbert