Re: libstdc++/10535

Re: libstdc++/10535

[Wolfgang Bangerth]

The following reply was made to PR libstdc++/10535; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/10535
Date: Wed, 30 Apr 2003 19:06:56 -0500 (CDT)

 ---------- Forwarded message ----------
 Date: Thu, 1 May 2003 00:59:22 +0100
 From: james.bannon <james.bannon@ntlworld.com>
 To: bangerth@ices.utexas.edu
 Cc: gcc-gnats@gcc.gnu.org, Begin-cpp <begin-cpp@accu.org>
 Subject: Update on: PR 10535
 
 Wolfgang,
 
 Sorry to mail you direct but the GNATS mailer seems to be broken as I keep
 getting bounce messages.
 
 Results of tests I have run tonight!
 
 Here's what I did:
 
 1.	Re-install Cygwin (cleaned & removed previous version & installed
 from scratch with gcc-3.2-3 (prerealease) binaries)
 2.	Downloaded gcc-3.2.3.tar.bz & bunzipped
 3.	Copy to /usr/tmp - not a symbolic link
 4.	Extracted the files to gcc-3.2.3 using tar xvf
 5.	Make directory /usr/tmp/build & change to that directory
 6.	Ran configure as follows:
 	../gcc-3.2.3/configure --prefix=/usr/local/gcc323
 --program-suffix=323 --enabled-shared
 	--enable-version-specific-runtime-libs --enable-languages=c,c++
 --disable-libgcj
 	Left the threading model & target alone for the configure script to
 choose as recommended in the documentation.
 7.	make bootstrap in build directory
 8.	Ran the test results with DEJAGNULIBS set to /usr/share/dejagnu &
 TCL_LIBRARY set to /usr/share/tcl8.4. Both of
 	these are OK according to the documentation. The tests appear to be
 the same as the other i686-pc-cygwin results 	submitted for this build in
 the e-mail archives so it wouldn't be worthwhile resubmitting them. They
 appear 
 	reasonable though are difficult to interpret.
 9.	make install
 	This installed the version-specific libraries in /usr/local/gcc323
 as expected, although /usr/local/gcc323/include
 	was empty and I found this a bit surprising as I was expecting the C
 stdlib headers to be in there.
 
 And here's the result:
 
 Ran the same elementary tests - same results! Even the extremely simple
 
 #include <string>
 int main()
 {
 	std:wstring wyde;
 }
 
 Gave precisely the same "wstring not defined in namespace std" error. The
 same thing happens when using wcout and wcin & friends; i.e, I am unable to
 instantiate specialisations for wchar_t. Again, specialisations exist but
 only if _GLIBCPP_USE_WCHAR_T is defined and defining this alone results in
 weird errors about missing #if expressions in a number of files in the bits
 directory. All this despite using the -l flag to explictly path to libstdc++
 and libsupc++ and -I to explicitly path to the include directory. 
 
 Strangely, the file cwchar exists and pulls in <wchar.h> under the control
 of the macro _GLIBCPP_HAVE_WCHAR_H. This does apparently inject the C
 standard library wide character functions into the std namespace if
 _GLIBCPP_HAVE_WCHAR_H is defined. Now wchar.h exists in the /usr/include
 directory, and apparently has the correct declarations, so presumably is
 being pulled in?
 
 I surely don't need a command line like the following:
 
 /usr/local/gcc323/bin/c++323 -D_GLIBCPP_USE_WCHAR_T -D_GLIBCPP_HAVE_WCHAR_H
 <infile> -o <outfile> -l/usr/local/gcc323/lib/i686-pc-cygwin/c++/libstdc++
 -l/usr/local/gcc323/lib/i686-pc-cygwin/c++/libsupc++
 
 To use wide characters! If I do have to do this as a hack then I can live
 with that but it must surely point to something being fundamentally broken
 either in the way the bootstrap process works or in the library itself, at
 least for the i686-pc-cygwin build! Support for both wide character strings
 and streams is vital to a project I'm planning as it needs to support
 UNICODE. Despite searches in the e-mail archives I can't find anything like
 this problem.
 
 Best Regards,
 James Bannon
 (When in doubt, try honesty!) 
 
 -----Original Message-----
 From: james.bannon [mailto:james.bannon@ntlworld.com] 
 Sent: 30 April 2003 20:06
 To: 'Wolfgang Bangerth'
 Subject: RE: PR 10535
 
 
 Thanks Wolfgang,
 
 I have reposted as suggested. I will have more by tomorrow. I plan to use
 the configure script to install a completely independent version for testing
 by making the libraries version-specific. Hopefully this will shed more
 light on whether it's me that's broken or the library!
 
 
 Best Regards,
 James Bannon
 (When in doubt, try honesty!) 
 
 -----Original Message-----
 From: Wolfgang Bangerth [mailto:bangerth@ices.utexas.edu] 
 Sent: 30 April 2003 15:00
 To: james.bannon@ntlworld.com
 Subject: PR 10535
 
 
 
 James, 
 emails get attached to an existing report if you cross-post to 
 gcc-gnats@gcc.gnu.org. Can you please send your mail about 10535 to this 
 address as well?
 
 Thanks
   W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 
 
 

Re: libstdc++/10535

[Technical Support]

The following reply was made to PR libstdc++/10535; it has been noted by GNATS.

From: Technical Support <support@isiuk.com>
To: "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: libstdc++/10535
Date: Thu, 1 May 2003 11:54:18 +0100 

 James Bannon
 
 Again posting from work.
 
 Having read Wolfgang's reply in the update, I recall seeing a message saying
 "checking for wchar_t ... no" appear during the boostrap procedure.
 Unfortunately, I don't have a copy of config.log (it was late last night and
 I deleted it!). I will try again!
 
 1.	Uninstall Cygwin & re-install.
 2.	Check /usr/include contains wchar.h & that the contents appear sane
 (no macros getting in the way). 
 3.	Check that I can use a couple of the functions as well.
 4.	Check my INCLUDE environment variable. I am a bit suspicious about
 this as /usr/include doesn't appear in the definition but most of the MSVC
 stuff does. I will
 	redefine it so that it *only* contains a reference to /usr/include
 to eliminate the possibility that configure is looking in the MSVC
 directories & can't find wchar.h.
 	I will also check the value of LIB as well.
 5.	Run the build again (this time saving all the logs!).
 6.	Run my tests again.
 7.	If they fail, I'll try defining the _GCPPLIB_USE_WCHAR_T and
 _GCPPLIB_HAVE_WCHAR_T macros in c++config.h or on the command line if I
 can't
 	define them there.
 8.	I will also try a build for MinGW to see if I get the same results.
 
 If all this fails, I'll send in the config.log. Otherwise I'll update the
 case as closed.
 
 Incidentally, a very similar problem (almost identical in fact) is reported
 for Sun and HP-UX as I discovered this morning when I searched the GNATS
 database again.
 
 
 Best Regards,
 James Bannon
 

Re: libstdc++/10535

[Wolfgang Bangerth]

The following reply was made to PR libstdc++/10535; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: "james.bannon" <james.bannon@ntlworld.com>
Cc: gcc-gnats@gcc.gnu.org, Begin-cpp <begin-cpp@accu.org>
Subject: Re: libstdc++/10535
Date: Wed, 30 Apr 2003 19:11:35 -0500 (CDT)

 > Sorry to mail you direct but the GNATS mailer seems to be broken as I keep
 > getting bounce messages.
 
 That's ok for gcc-prs and nobody@... It's a brokenness in GNATS. If you 
 want something to be appended to a report, you will also have to have a 
 subject line like the one above.
 
 Regarding all the rest: I don't think I can be of any help here, 
 unfortunately, not having any knowledge of cygwin or gcc internals. My 
 best guess is that wide chars are disabled in your installation since the 
 configure script detected something so it thought wide characters don't 
 exist (or don't work) on your system. It would then simply switch off 
 everything that has to do with wchar_t etc. So I think the only advice I 
 can give is: try to go through the output of configure and see whether 
 there's something related. Usually, it looks like
   checking for wchar_t... no
 To find out why it got the negative answer, you may look at the test that 
 was actually performed in config.log.
 
 Sorry to be of no more help, regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/