John Maddock wrote:

[...] as you noticed gcc on HPUX doesn't get tested that much [...]

John, this is no longer the case. Two HP-UX platforms are tested with gcc on a regular basis: HP-UX_pa_risc_gcc and HP-UX_ia64_gcc. On both, all regex tests pass (I'm not implying that they should be failing because of this configuration issue). Thanks, Boris ----- Original Message ----- From: "John Maddock" To: Sent: Sunday, January 20, 2008 4:39 AM Subject: Re: [Boost-users] Boost, HP-UX and gcc

Martin_Thomas@McAfee.com wrote:

...

I am trying to use use Boost::Regex on HP 11i with gcc 4.2.2 and I notice that in config/platform/hpux.hpp there is a define to turn off wide-char support unless using aCC and have a1 source eg:

#if !(defined(__HP_aCC) || !defined(_INCLUDE__STDC_A1_SOURCE))

# define BOOST_NO_SWPRINTF

# define BOOST_NO_CWCTYPE

#endif

This will never allow gcc to use wregex even if wchar support is available. Is this because there are so few people using Zgcc oin HP-ux or am I missing something? On the assumption that it is related to usage, I have added the following to allow gcc 4 to use wregex:

#if defined(__GNUC__)

# if (__GNUC__ >3)

# undef BOOST_NO_CWCTYPE

# endif

#endif

Is there anything obviously wrong with this?

No it should work OK: as you noticed gcc on HPUX doesn't get tested that much so our config information may well be out of date.

HTH, John.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Martin_Thomas@McAfee.com wrote:

Boris, I don't believe I found any documentation, just an empirical observation that somewhere after gcc 3.3.x wchar is available but not knowing when exactly, played safe with requiring gcc > 4.0.

I've looked into this some more, and at least on the td176 HP testdrive machine with gcc-4.1.0 wide character support in the std library is *not* enabled :-( You can include <cwchar> but it doesn't import anything into namespace std, and there's also no std::wstring in <string> etc :-( 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. Regards, John.

...

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