Re: [Boost-users] Boost, HP-UX and gcc

From: Michael Linck (mgl_at_[hidden])
Date: 2008-01-22 18:33:37

> >So... I've changed the HPUX config not to unconditionally disable wide
> >character support for gcc, but none the less, it will be disabled by
> >booct/config/stdlib/libstdcpp3.hpp since neither _GLIBCPP_USE_WCHAR_T
> >nor
> >_GLIBCXX_USE_WCHAR_T are defined by gcc's std lib.

Hi, just noticed this thread.  I had to port my company's project (which
uses boost) to hpux a few months back.  This may be excessive, but here
are is a copy of the notes I kept from that experience.  Some of this,
you might find useful.  I don't know what version of HPUX you're working
with.  The notes are unedited, except that I removed my use of
profanity:

compilation
error: /home/mlinck/develop/api/tp-sources-trunk/boost_1_33_1/boost/regex/v4/regex_traits_defaults.hpp:87:94: error: missing binary operator before token "0"
  * Turned out that this is a bug in HPUX 11.23, fixed in HPUX11.31.
    Here's a link to the thread:
    http://lists.boost.org/Archives/boost/2006/09/110505.php
  * found workaround in same thread above
              * that workaround does *not* work. Added code at top of
                bad header file: #ifdef hpux #include <wchar.h> #undef
                WCHAR_MIN /* (wchar_t)0 */ #define WCHAR_MIN 0 #endif
              * error simply changed
                to: /home/mlinck/develop/api/tp-sources-trunk/boost_1_33_1/boost/regex/v4/regex_traits_defaults.hpp:94:28: error: missing binary operator before token "("
              * tried a different workaround at the code where the error
                is thrown. Noticed that broken code gets skipped for
                HP_aCC compiler. Figure we can maybe get away with same
                for gcc compiler:
                        => #if !defined HP_aCC && !defined hpux
                        
      * seems to compile. Had to apply to
        boost/regex/v4/perl_matcher.hpp as well

.
.
.
later in the notes (linking phase)

      * trouble using the boost thread library 
      * so far, all the other boost stuff has been linked in suprisingly
        easily, with a crap ton of warnings, due to a stricter compiler,
        but otherwise no prob. This one just totally bombs out, though.
      * problem persists, realized that the output from building is
        exactly as if the thread lib weren't present (though it is).
        Must be failing to include it as a library target or something,
        to the proctable library, for some reason.
      * Had to ensure that boost uses pthreads
      * * boost/config/platform/hpux.hpp now defines # define
        BOOST_SP_USE_PTHREADS
.
.
.
boost... [expletive]-ing boost: 
      * ultimately - after trying at least a dozen other approaches -
        fixed by doing the following: 
              * found tools/build/v1/gcc-tools.jam and searched for
                occurences of -Ox and inline. changed all occurrences of
                related compiler options to O1 and fno-inline, even ones
                that were previously used 
              * Note that this fix will slow down boost down somewhat on
                all other platforms
My last build problem with boost threads (a runtime core) ended up being
resolved when I rebuilt *everything else* (i.e. all other tp libraries
we use and our own source) to explicitly use pthreads wherever
appropriate.

- mike