Good day, I'm trying to port Boost to SCO Unix using STLport and GNU Pth (a user-space Pthreads library), and gcc 2.95 controlled by a customized compiler driver (so some of the following observations may not be applicable to stock gcc users on this platform). Anyway, I've had a few problems that I'd like to report; I think at least some of them are worth correcting in future Boost releases: 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. ** checking pthread_yield... no This is correct, but I do have a pthread_yield_np() function, maybe we should look for it, too. ** 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. I also discovered some problems with Jamfiles (BTW what is Jamfile.v2? Is it useable? How does one use it?): tools/build/v1/allyourbase.jam, near line 574): rule CcMv is called but never defined. What does variable "RELOCATE" do in allyourbase.jam? It seems to indicate that the compiler doesn't support the -o switch, shouldn't this be defined in compiler-specific toolset files? 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? The documentation (http://www.boost.org/more/getting_started.html#Build_Install) states that "[...] For toolsets that support it in Unix they will also have a full version extension (for example ".so.1.31.0")". But this does not seem to be the case. I ended up with "libboost_thread-gcc-mt-1_31.so" etc. using gcc toolset on SCO. Where are the ".so.1.31.0" versions? Maybe I'm missing some toolset settings. Also it seems that some of the .so files generated ought to be symbolic links, but are instead copies of one another. Where is this controlled? Do I need to edit/create some toolset file to replace "cp" with "ln -s"? 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. It would be nice to have an option of not using the long "mangled" library names while installing. As a user I would expect a more customary convention for library names on UNIX-like systems, with only two variants, something like the following: libboost_foo.a libboost_foo.so.1.31.0 libboost_foo.so (symbolic link to libbost_foo.so.1.31.0) (... possibly more links depending on binary compatibility guarantees between the releases) both compiled with MT/non-debug configurations. Comments/suggestions? Thanks, D.