I just installed gcc 3.4.1 on HP-UX 11i and I'm unable to compile the following test case: #include <string> int main () { std::wstring s; }; with error about wstring not in std namespace because _GLIBCPP_USE_WCHAR_T is commented out in the c++config.h file.
Hi. Are you sure that the gcc3.4.1 build and installation is completely sane? I'm puzzled since, according to libstdc++/10041, everything should be ok...
Confirmed. I get 17005.C: In function `int main()': 17005.C:4: error: `wstring' is not a member of `std' 17005.C:4: error: expected `;' before "s" Despite Paolo's comment, I don't think this ever worked.
In building the 3.4 branch, the following possibly relevant configure tests don't find needed support: checking wctype.h usability... no checking wctype.h presence... no checking for wctype.h... no checking for enabled wchar_t specializations... no Does the absence of wctype.h and specializations prevent wstring from working? It appears that the claim in PR 10441 that the bug is fixed was incorrect (unless it re-broke sometime between 3.4.0 and 3.4.1).
> Does the absence of wctype.h and specializations prevent wstring from working? wctpye.h is important for locale, for the ctype facet, but shouldn't prevent wstring from working... Probably in our autoconf tests we are lacking a finer grained enabling/disabling of the features...
I checked and I have /usr/include/wctype.h. See my config.log below. I'm missing the WCHAR_MIN and WCHAR_MAX. I've tried export CPPFLAGS=-D_INCLUDE__STDC_A1_SOURCE before configure & make bootstrap but as the config.log below shows, my CPPFLAGS is not getting included in the command line. Isn't that what CPPFLAGS is for? configure:24821: checking wctype.h presence configure:24832: /pics/log/ccase/gcc-3.4.1-objdir/gcc/xgcc - B/pics/log/ccase/gcc-3.4.1-objdir/gcc/ -B/usr/local/appl/gcc/hppa 2.0w-hp-hpux11.11/bin/ -B/usr/local/appl/gcc/hppa2.0w-hp-hpux11.11/lib/ - isystem /usr/local/appl/gcc/hppa2.0w-hp-hpux11.11/in clude -isystem /usr/local/appl/gcc/hppa2.0w-hp-hpux11.11/sys-include -E -O2 -g - O2 conftest.c configure:24838: $? = 0 configure:24857: result: yes configure:24893: checking for wctype.h configure:24900: result: yes configure:24923: checking for WCHAR_MIN and WCHAR_MAX configure:24942: /pics/log/ccase/gcc-3.4.1-objdir/gcc/xgcc - B/pics/log/ccase/gcc-3.4.1-objdir/gcc/ -B/usr/local/appl/gcc/hppa 2.0w-hp-hpux11.11/bin/ -B/usr/local/appl/gcc/hppa2.0w-hp-hpux11.11/lib/ - isystem /usr/local/appl/gcc/hppa2.0w-hp-hpux11.11/in clude -isystem /usr/local/appl/gcc/hppa2.0w-hp-hpux11.11/sys-include -c -O2 -g - O2 -O2 -g -O2 conftest.c >&5 configure: In function `main': configure:24996: error: `WCHAR_MIN' undeclared (first use in this function) configure:24996: error: (Each undeclared identifier is reported only once configure:24996: error: for each function it appears in.) configure:24996: error: `WCHAR_MAX' undeclared (first use in this function) configure:24945: $? = 1 configure: failed program was:
Jerry, you have HP-UX 11.11, I have 11.0. Presumably that explains the difference; my system lacks /usr/include/wctype.h, and places the definitions for the functions like iswalnum that the Open Group says belong in wctype.h, into wchar.h instead.
I stuck -D_INCLUDE__STDC_A1_SOURCE into CFLAGS but I get the following 2 errors during make bootstrap. /pics/log/ccase/gcc-3.4.1-objdir/gcc/include/wchar.h:87: error: `va_list' has not been declared Should va_list in the following lines be __gnuc_va_list as they are in the other headers like stdio.h? extern int vfwprintf __((FILE *, const wchar_t *, va_list)); extern int vwprintf __((const wchar_t *, va_list)); extern int vswprintf __((wchar_t *, size_t, const wchar_t *, va_list)); /usr/include/sys/_mbstate_t.h:11: error: 'mbstate_t' has a previous declaration as `typedef struct mbstate_t mbstate_t' /pics/log/ccase/gcc-3.4.1-objdir/hppa2.0w-hp-hpux11.11/libstdc++- v3/include/cwchar:65: error: declaration of `typedef struct mbstate_t mbstate_t'
> Should va_list in the following lines be __gnuc_va_list as they are in the > other headers like stdio.h? Yes. I've known about this for sometime. I think there are a couple of other headers on 11i that use va_list and don't get fixed as well. The problem is not specific to gcc 3.4. It affects all gcc versions. Until someone works out a fixinclude patch, I suggest copying wchar.h into gcc's internal include directory. Then, manually change va_list to __gnuc_va_list. However, this won't fix any problems in the libstdc++ build unless you redo it with the fixed header(s).
There's a name clash occuring for struct mbstate_t, which is double defined as shown below. Would somebody pls. give me guidance on how this might be resolved? Thanks! include/c++/3.4.1/cwchar extern "C" { typedef struct { int __fill[6]; } mbstate_t; } /usr/include/sys/_mbstate_t.h typedef struct { unsigned char __parse_size:3; unsigned char __dummy:4; unsigned char __shift_state:1; char __parse_buf[7]; } mbstate_t;
I think that we can resolve the the namespace conflict by adding the following to the hpux os_defines.h: /* HP-UX 11i has mbstate_t when _MBSTATE_T is defined. */ #if !defined(_GLIBCXX_HAVE_MBSTATE_T) && defined(_MBSTATE_T) #define _GLIBCXX_HAVE_MBSTATE_T #endif I have a patch for the va_list problem under test. I'm not sure about _INCLUDE__STDC_A1_SOURCE.
Subject: Re: wide character strings don't work on HP-UX > I have a patch for the va_list problem under test. http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00960.html > I'm not sure about _INCLUDE__STDC_A1_SOURCE. The enclosed patch adds the C99 wide character support to the default GCC namespace except when using C89. This enables the wide character specializations when libstdc++ is built. However, the patch as it currently stands introduces four regressions in the libstdc++ testsuite: FAIL: 22_locale/time_put/put/wchar_t/1.cc execution test FAIL: 22_locale/time_put/put/wchar_t/10.cc execution test FAIL: 22_locale/time_put/put/wchar_t/5.cc execution test FAIL: 22_locale/time_put/put/wchar_t/9.cc execution test I looked at the first one a bit: Assertion failed: result1 == L"Sun", file /test/gnu/gcc-3.3/gcc/libstdc++-v3/tes tsuite/22_locale/time_put/put/wchar_t/1.cc, line 53 FAIL: 22_locale/time_put/put/wchar_t/1.cc execution test The wchar_t * in result1 is null. I'm not sure why. With this change, the testcase will build under HP-UX 11i. However, it's not going to fix the problem on earlier HP-UX 11 releases. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) Index: config/pa/pa-hpux11.h =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/pa/pa-hpux11.h,v retrieving revision 1.14 diff -u -3 -p -r1.14 pa-hpux11.h --- config/pa/pa-hpux11.h 27 Apr 2004 00:12:30 -0000 1.14 +++ config/pa/pa-hpux11.h 14 Aug 2004 17:40:50 -0000 @@ -24,7 +24,12 @@ Boston, MA 02111-1307, USA. */ the definition of __cplusplus. We define _INCLUDE_LONGLONG to prevent nlist.h from defining __STDC_32_MODE__ (no longlong support). We define __STDCPP__ to get certain system headers - (notably assert.h) to assume standard preprocessor behavior in C++. */ + (notably assert.h) to assume standard preprocessor behavior in C++. + + The C99 support is incomplete. We define _INCLUDE__STDC_A1_SOURCE + to provide the extended multibyte and wide-character utilities available + under HP-UX 11i. Defining _HPUX_SOURCE would give us some more + features but it also adds stuff that isn't in C99. */ #undef TARGET_OS_CPP_BUILTINS #define TARGET_OS_CPP_BUILTINS() \ do \ @@ -41,6 +46,7 @@ Boston, MA 02111-1307, USA. */ { \ builtin_define ("_HPUX_SOURCE"); \ builtin_define ("_INCLUDE_LONGLONG"); \ + builtin_define ("_INCLUDE__STDC_A1_SOURCE"); \ builtin_define ("__STDC_EXT__"); \ builtin_define ("__STDCPP__"); \ } \ @@ -49,6 +55,7 @@ Boston, MA 02111-1307, USA. */ if (!flag_iso) \ { \ builtin_define ("_HPUX_SOURCE"); \ + builtin_define ("_INCLUDE__STDC_A1_SOURCE"); \ if (preprocessing_trad_p ()) \ { \ builtin_define ("hp9000s800"); \ @@ -62,6 +69,10 @@ Boston, MA 02111-1307, USA. */ else \ builtin_define ("__STDC_EXT__"); \ } \ + else if (flag_isoc99) \ + { \ + builtin_define ("_INCLUDE__STDC_A1_SOURCE"); \ + } \ if (!TARGET_64BIT) \ builtin_define ("_ILP32"); \ } \
Thanks Dave! I look forward to see your patch in, then we can work together on the final details: 4 failures for the entire wchar_t testsuite is a *very* good start!
Subject: Bug 17005 CVSROOT: /cvs/gcc Module name: gcc Changes by: danglin@gcc.gnu.org 2004-08-14 19:02:58 Modified files: gcc : ChangeLog gcc/config/pa : pa-hpux11.h Log message: PR libstdc++/17005 partial fix. * pa-hpux11.h (TARGET_OS_CPP_BUILTINS): Define _INCLUDE__STDC_A1_SOURCE except when generating ANSI/C89 code. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.4908&r2=2.4909 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa-hpux11.h.diff?cvsroot=gcc&r1=1.14&r2=1.15
Note that C94 requires wchar_t support too.
Subject: Re: wide character strings don't work on HP-UX > ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-08-14 > 19:27 ------- > Note that C94 requires wchar_t support too. I believe that we have wchar_t without defining _INCLUDE__STDC_A1_SOURCE. It adds mbstate_t, WCHAR_MAX, WCHAR_MIN, etc. Are these in C94? I don't have a copy of the C94 specification. Dave
Hi everyone, hi Dave. > The wchar_t * in result1 is null. I'm not sure why. You mean *result1.data() is a '\0'? Or result1.data() is a null pointer? In the first case time_put::do_put is totally failing, in the last case even worse things are happening... Anyway, time_put::do_put basically does this, in "C terms": #include <locale.h> #include <time.h> #include <wchar.h> #include <string.h> #include <assert.h> int main() { wchar_t __s[64]; int __maxlen = 64; wchar_t __format[3] = L"%a"; struct tm __tm = { 0, 0, 12, 4, 3, 71, 0, 93, 0 }; wcsftime(__s, __maxlen, __format, &__tm); assert(wcscmp(__s, L"Sun") == 0); } Can you debug a bit further? Thanks, Paolo.
Subject: Re: wide character strings don't work on HP-UX > You mean *result1.data() is a '\0'? Or result1.data() is a null pointer? I believe the former. > Anyway, time_put::do_put basically does this, in "C terms": > > #include <locale.h> > #include <time.h> > #include <wchar.h> > #include <string.h> > #include <assert.h> > > int main() > { > wchar_t __s[64]; > int __maxlen = 64; > wchar_t __format[3] = L"%a"; > struct tm __tm = { 0, 0, 12, 4, 3, 71, 0, 93, 0 }; > > wcsftime(__s, __maxlen, __format, &__tm); > > assert(wcscmp(__s, L"Sun") == 0); > } > > Can you debug a bit further? Thanks, Paolo. The wcsftime call isn't working. The return value is 0 indicating that the results in __s are undefined. Changing the third argument to "const char *" works. I think that I have found the problem. # ifdef _INCLUDE__STDC_A1_SOURCE extern size_t wcsftime __((wchar_t *, size_t, const wchar_t *, const struct tm *)); # else /* ! _INCLUDE__STDC_A1_SOURCE */ extern size_t wcsftime __((wchar_t *, size_t, const char *, const struct tm *)); # endif /* _INCLUDE_STDC_A1_SOURCE */ The third argument is different when _INCLUDE__STDC_A1_SOURCE is defined. It would appear that we either need to do something different when _INCLUDE__STDC_A1_SOURCE is defined. We seem have the following in libc.a: Symbols from libc.a[wcsftime.o]: __wcsftime_std | 0|extern|entry |$CODE$ _wcsftime | 252|extern|entry |$CODE$ wcsftime | 252|sdef |entry |$CODE$ __wcsftime_std | |undef |code | Dave
> The wcsftime call isn't working. The return value is 0 indicating > that the results in __s are undefined. Changing the third argument > to "const char *" works. I see... I do not understand well what you are saying below: the standard mandated type for the third argument is const wchar_t* and from what you are writing it seems that _INCLUDE__STDC_A1_SOURCE gets it right, *not* viceversa! Thanks to your patch, _INCLUDE__STDC_A1_SOURCE is now defined (right?) so I cannot understand why on this target wcsftime expects a (wrong) const char*!
Subject: Re: wide character strings don't work on HP-UX > I see... > I do not understand well what you are saying below: the standard mandated > type > for the third argument is const wchar_t* and from what you are writing it > seems > that _INCLUDE__STDC_A1_SOURCE gets it right, *not* viceversa! Right. > Thanks to your patch, _INCLUDE__STDC_A1_SOURCE is now defined (right?) so I > cannot understand why on this target wcsftime expects a (wrong) const char*! It sort of looks as if HP may have written this stuff ... I'm still looking at this but it looks as if the code switches behavior depending on some bit in the variable __xpg4_extended_mask. Dave
Subject: Re: wide character strings don't work on HP-UX > > Thanks to your patch, _INCLUDE__STDC_A1_SOURCE is now defined (right?) so I > > cannot understand why on this target wcsftime expects a (wrong) const char*! It looks as XPG4 defined the function differently from NA1 ;( > It sort of looks as if HP may have written this stuff ... I'm still > looking at this but it looks as if the code switches behavior depending > on some bit in the variable __xpg4_extended_mask. It's bit 26 in __xpg4_extended_mask that toggles the behavior. This is a can of worms. The bits are undocumented. I don't really have a good way of setting them as they need to be set at runtime. I think to do this right we need wrappers for all functions that use __xpg4_extended_mask so that the desired mode can be set before each call. I'm thinking about backing out the _INCLUDE__STDC_A1_SOURCE change. Dave
Subject: Re: wide character strings don't work on HP-UX 11i using gcc 3.4.1 This is a work in progress. In one sense, the patch is complete except for documenting the -munix= option. However, it's dangerous to use other than default for this option. The start file selection adds unix95.o or unix98.o when using UNIX 95 and 98, respectively. The sole function of these files is to provide a start of value for the int __xpg4_extended_mask. The supported values are: UNIX __xpg4_extended_mask 93 0 95 0xf 98 0x6f The mask value alters the behavior of various functions (e.g., wcsftime -- third argument changes from const char * to const wchar_t *). I'm trying to decide if further work is needed. If no one uses anything but the default values, there's no problem. However, library code that uses the xpg4 extended support really needs to save, set and restore the __xpg4_extended_mask when it uses functions affected by the mask value. I'm trying to decide whether this should be done automatically. However, the list is fairly long and it's a bit tricky to determine all the interactions. Comments? Dave
Created attachment 6970 [details] pa-xpg4.d
Subject: Re: wide character strings don't work on HP-UX 11i using gcc 3.4.1 John David Anglin wrote: >This is a work in progress. In one sense, the patch is complete >except for documenting the -munix= option. > First, thanks for your work: if I understand well, on 11.11, and default for -munix, we have obtained a clean wchar_t testsuite: great! > However, it's dangerous >to use other than default for this option. > > Unfortunately, I have trouble understanding the details of your concerns: hopefully, someone else will give you more meaningful advice. My naive impression is that the new, documented, default, cannot be really dangerous, by itself and the same for well documented new options. Also, if I understand well, those options (93, 95, that is) can only lead to a behavior similar to what we had before your patch... On the other hand, if this is not the case, in my opinion you could work on adding that possibility. Thanks again, Paolo.
Subject: Re: wide character strings don't work on HP > John David Anglin wrote: > > >This is a work in progress. In one sense, the patch is complete > >except for documenting the -munix= option. > > > First, thanks for your work: if I understand well, on 11.11, and default > for -munix, we have obtained a clean wchar_t testsuite: great! Yes, that seems to work. > > However, it's dangerous > >to use other than default for this option. > > > > > Unfortunately, I have trouble understanding the details of your concerns: > hopefully, someone else will give you more meaningful advice. My naive > impression is that the new, documented, default, cannot be really dangerous, > by itself and the same for well documented new options. Also, if I > understand well, those options (93, 95, that is) can only lead to a behavior > similar to what we had before your patch... On the other hand, if this is > not the case, in my opinion you could work on adding that possibility. I've thought a bit more about this issue. The fundamental problem is that library code has to be aware of the ABI changes in the different XOPEN UNIX standards if it's going to support more one standard. The interface changes for some functions. In other cases, it's just the operational behavior that changes. Libraries might need conditionalized headers to support these differences. While I could set the __xpg4_extended_mask on a per function basis when I detect the use of a XPG4 extended feature, this isn't a full solution for library code that needs to work with user code compiled using a different standard. For that, library code has to check, set and restore the __xpg4_extended_mask value as appropriate. Thus, I think attempting to provide more than the correct predefines and start files is probably a mistake. If libstdc++-v3 is built with -munix=98, it's not going to work correctly with a user application linked with -munix=93 or -munix=95 as some of the wide character support changes its operational behavior (e.g., wcsftime). I can't really see people that develop library code adding the HP-UX 11 specific tests needed to support multiple XOPEN UNIX standards. It appears that glibc only provides the UNIX 98 multibyte features. I think that for open source code support we want to adopt HP-UX features that match as closely as possibly the features the GNU source features. I need to check if we should default to UNIX 93 or UNIX 95 for HP-UX 10.10 to 11.00 (just discovered that UNIX 95 support started with HP-UX 10.10). Probably, UNIX 95 would be best for GNU compatibility. On the otherhand, UNIX 93 is the HP compiler default and nobody has complained yet... Life would be simpler if GCC only supported one XOPEN UNIX standard on any given HP-UX target (i.e., no -munix= option). However, the option does given more flexibility even if it requires some considerably sophistication to use. Dave
Subject: Bug 17005 CVSROOT: /cvs/gcc Module name: gcc Changes by: danglin@gcc.gnu.org 2004-08-25 17:49:59 Modified files: gcc : ChangeLog config.gcc gcc/config/pa : pa-hpux.h pa-hpux10.h pa-hpux11.h pa.c pa.h pa64-hpux.h gcc/doc : install.texi invoke.texi Added files: gcc/config/pa : pa-hpux1010.h pa-hpux1111.h Log message: PR libstdc++/17005 (fix for HP-UX 11.11) * config.gcc (hppa*-*-*): Move MASK_BIG_SWITCH to target_cpu_default2. (hppa*-*-hpux*): Consolidate hppa1.0-*-* code. Rework handling of tm_file including pa-hpux1010.h or pa-hpux1111.h when appropriate. * config/pa/pa-hpux1010.h, config/pa/pa-hpux1111.h: New files. * config/pa/pa-hpux.h (TARGET_HPUX): Define. (LINK_SPEC): Handle march=1.0 option. * config/pa/pa-hpux10.h (TARGET_OS_CPP_BUILTINS): Predefine _XOPEN_UNIX and _XOPEN_SOURCE_EXTENDED for UNIX 95. (SUBTARGET_OPTIONS): New define. (LINK_SPEC): Handle march=1.0 option. (STARTFILE_SPEC): New define. * config/pa/pa-hpux11.h (TARGET_OS_CPP_BUILTINS): Predefine _XOPEN_UNIX and _XOPEN_SOURCE_EXTENDED for UNIX 95. Additionally, predefine _INCLUDE__STDC_A1_SOURCE and _INCLUDE_XOPEN_SOURCE_500 for UNIX 98. (SUBTARGET_OPTIONS): New define. (LINK_SPEC): Handle march=1.0 option. (STARTFILE_SPEC): New define. * config/pa/pa.c (override_options): Add code to process -munix= option. * config/pa/pa.h (pa_unix_string, flag_pa_unix): Declare. (TARGET_HPUX, TARGET_HPUX_10_10, TARGET_HPUX_11_11): Provide default defines. (TARGET_OPTIONS): Add SUBTARGET_OPTIONS to option list. (SUBTARGET_OPTIONS): Provide default define. * config/pa/pa64-hpux.h (STANDARD_STARTFILE_PREFIX_1, STANDARD_STARTFILE_PREFIX_2): New defines. (STARTFILE_SPEC): Provide unix95.o or unix98.o startfiles as necessary. (ENDFILE_SPEC): Use %O. * doc/install.texi (hppa*-*-hpux*): Reword paragraph on -g and gas. Mention issue caused by changing namespace and runtime to UNIX 95/98. * doc/invoke.texi (HPPA options): Move misplaced text to FRV options. Document -munix=std option. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5083&r2=2.5084 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.gcc.diff?cvsroot=gcc&r1=1.481&r2=1.482 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa-hpux1010.h.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa-hpux1111.h.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa-hpux.h.diff?cvsroot=gcc&r1=1.14&r2=1.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa-hpux10.h.diff?cvsroot=gcc&r1=1.20&r2=1.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa-hpux11.h.diff?cvsroot=gcc&r1=1.15&r2=1.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa.c.diff?cvsroot=gcc&r1=1.274&r2=1.275 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa.h.diff?cvsroot=gcc&r1=1.232&r2=1.233 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa64-hpux.h.diff?cvsroot=gcc&r1=1.35&r2=1.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/install.texi.diff?cvsroot=gcc&r1=1.308&r2=1.309 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.514&r2=1.515
Fixed for 3.5.0.
*** Bug 19725 has been marked as a duplicate of this bug. ***
Exists there any version of gcc3 newer than 3.2.3 that supports std::wstring on HP-UX11.11??? I have unsuccesfull tested: gcc-3.3.5, gcc-3.4.3 and gcc-4.0 does not compile on hp-ux. Problems with varargs... Is there any working solution to build a compiler that support wstring???
> I have unsuccesfull tested: gcc-3.3.5, gcc-3.4.3 and gcc-4.0 does not compile > on hp-ux. Problems with varargs... There is no released version, but the forthcoming 4.0 will be ok. To my best knowledge, hppa-hpux builds fine, currently and indeed, the wchar_t testsuite is clean http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg00043.html if not, for you, please file a separate PR. Thanks.
Subject: Re: wide character strings don't work on HP-UX > ------- Additional Comments From pcarlini at suse dot de 2005-02-02 13:30 > ------- > > I have unsuccesfull tested: gcc-3.3.5, gcc-3.4.3 and gcc-4.0 does not > compile > > on hp-ux. Problems with varargs... GCC doesn't use varargs. Varargs problems have been reported before and I believe that you may be trying to use a broken HP build of GCC as your bootstrap compiler. GCC fixes various headers and it may contain a version of varargs.h in its directory of fixed headers. This might also happen using HP sed. Read the hppa install notes carefully. If you have to start with the HP bundled compiler, you will first have to build a version from the 3.3 branch before using it to build later versions. If you have a recent version of HP ANSI C, you should be able to build 4.0 directly. Also, make sure that your build tree isn't in the source tree. Dave
The Problem was using gcc-3.2 as bootstrap compiler. After using the system cc the bootstrap finished successfully. Now my g++ supports wstring :-D Thanks to all!
Now I have similar problem on HP-UX 11.00 (32). gcc does not find any definition of std::wstring. std::string is not useable too, in cause of unsatisfied symbols. A similar configuration works on HP-UX 11.11 (64). Has anybody an idea howto solve the problem?
Unfortunately, bad news: if I remember correctly, Dave doesn't mean to fix the problem on anything older that 11.11...
Whats the plan? Is it possibile that the problem would be fixed next time?
Subject: Re: wide character strings don't work on HP-UX > ------- Additional Comments From pcarlini at suse dot de 2005-03-01 11:01 > ------- > Unfortunately, bad news: if I remember correctly, Dave doesn't mean to fix > the > problem on anything older that 11.11... Yes, I believe that this is correct. The HP libc doesn't provide the support needed prior to 11.11. There is a HP web page that shows the timeline for the addition of various C95 (NA 2) and C99 features. Even with 11.11, the initial bootstrap requires special defines to allow configure to detect the wide character support (there is an issue with the declaration of iconv). I use for 4.x 32-bit builds with gcc versions prior to 4.0.0: export CC="gcc -D_XOPEN_UNIX -D_XOPEN_SOURCE_EXTENDED -D_INCLUDE__STDC_A1_SOURCE -D_INCLUDE_XOPEN_SOURCE_500" Dave