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