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 #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
