[boost] Porting to SCO Unix

From: Davlet Panech (davlet_panech_at_[hidden])
Date: 2004-08-31 19:54:51

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.