Re: [boost] Porting to SCO Unix

From: John Maddock (john_at_[hidden])
Date: 2004-09-02 05:07:47

> The following tests in libs/config/configure produce incorrect results:
>
> ** checking for pthread_exit in -lpthread... no
> This test tries to compile a C source file that prototypes "pthread_exit" 
> as
> "char pthread_exit();". But my compiler    driver always adds "-include
> <...>/pthread.h" to the command line, which includes a different,
> conflicting prototype for this function. I think the test ought to include
> <pthread.h> instead.

Grrrrr, I used the standard autoconf macros for checking this, if I get the 
time I'll try and write my own version that does what you suggest.

> ** checking pthread_yield... no
> This is correct, but I do have a pthread_yield_np() function, maybe we
> should look for it, too.

It's up to the thread lib guys to use it (or not), maybe you could hassle 
the authors of the thread lib you are using to provide a standard function 
signature?

> ** checking  std::basic_streambuf<wchar_t> ... OK
> I think this should fail if _STLP_NO_WCHAR_T is defined, which it is in my
> STLport configuration headers. This macro does not prevent one from
> instantiating basic_string<>, etc. with wchar_t, but it does disable
> explicit instantiations of these in STLport binaries. So 
> basic_string<char>
> ends up being compiled into libstlport.so, while basic_string<wchar_t>
> doesn't. The macro also disables the typedefs (wstring, wcout, etc) and 
> the
> wide char - related C headers (<cwchar>, <cwctype>). I really think Boost
> should disable all wide char stuff in this case.

Do BOOST_NO_CWCTYPE and BOOST_NO_CWCHAR get defined?  If so then this is a 
non-issue as support for wide character strings/streams will get 
automatically disabled off the back of this (in other words the message may 
be misleading).

> Why is there no static version of Boost.Threads? I know this is required 
> in
> Windows, but not if it's compiled on top of Pthreads on any platform (I'm
> using pthreads-win32 from Redhat, on Windows), right?

There will be a static version in the next release.

> If I pass -DNDEBUG to my source files that #include Boost headers, do I 
> have
> to link with non-debug version of boost libs? How about multithreaded vs
> single-threaded configurations? For example, is it safe to link with MT
> Boost libs with non-MT programs using gcc/Linux? I know it makes a
> difference in Windows, but it should not matter on platforms where 
> compiler
> runtimes don't differentiate between MT/non-MT, IMHO. That is, unless the
> Boost headers provide different declarations depending on the presence of
> some "MT" macro. This would be very unfortunate, because it's very easy to
> link with the wrong library and the compiler won't complain about it.

You must link to a library compiled the same way as your code, and yes the 
multithreaded binaries are generally binary-incompatible with single 
threaded code (technical note - because boost code is a mix of templates and 
separate file code, we can't in general shield users from issues like this, 
at least not without some people complaining :-) )

John.