Dear John,
I totally agree that it's almost impossible for Boost config headers
to detect if correct options are specified at command line and if the
pthreads library installed works correctly or not. However, it seems
to me that the criterion whether BOOST_HAS_THEADS macro is defined or
not for a specific platform is ambiguous. From my viewpoint, if one
wants to use Boost.thread library, she/he should be responsible to
prepare correct version of pthread library and provide appropriate
comand line options to the compiler. Thus consistent ways for
defining BOOST_HAS_THREADS would be
i) define BOOST_HAS_THREADS if there exists at least one environment
(library version and compiler options). The user who wants to use
Boost.thread is responsible for the environment.
ii) BOOST_HAS_THREADS is always undefined. The user define it by hand
if she/he needs Boost.thread and is confident of providing a
correct environment.
If we adopt the strategy i, BOOST_HAS_THREADS should be defined also
for KAI C++, and Intel C++ (and others) as well as for GCC, Compaq,
SGI, etc. If ii, BOOST_HAS_THREADS should be removed from all the
current Boost config headers. In any case, user programs which do not
use Boost.thread will be left unaffected.
Synge Todo
[EMAIL PROTECTED]
At Thu, 12 Dec 2002 12:27:02 -0000,
John Maddock wrote:
>
> > i) Linux with KAI C++, Intel C++
> >
> > On Linux, BOOST_HAS_PTHREADS macro is defined only if we use gcc
> > (config/compiler/gcc.hpp), but it's not defined for other compilers
> > (KAI, Intel, etc). I found that boost.thread compiles successfully by
> > the latter compilers if I defined BOOST_HAS_PTHREADS macro (and
> > BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) by hand, and all the examples
> > worked fine. Is there any reason why these macros are not defined for
> > these compilers??
>
> It is almost certain that there is a compiler switch that you need to turn
> on (often -pthread or something like it - consult your compilers
> documentation). Simply defining BOOST_HAS_THREADS without this will get
> your code compiling but it is very unlikely to work correctly.
>
> > ii) Compaq Tru64 with Compaq C++ and SGI IRIX with MIPSPro Compiler
> >
> > The example program for recursive mutex (libs/thread/example/
> > recursive_mutex.cpp) compiles on these platforms, but it crashes or
> > ends up with deadlock if I try to run it. At the moment, I'm not sure
> > where the problem is in recursive mutex implementation. If I undefine
> > BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE, it works without any problem.
>
> I don't know if this is the issue, but if you search sgi.com for "pthread"
> there do seem to be a lot of OS-patches to the pthread lib available.
> Probably you need to address this issue on an SGI specific group though to
> find out which IRIX versions have a working pthread_mutexattr_settype.
>
> John Maddock
> http://ourworld.compuserve.com/homepages/john_maddock/index.htm
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
