Re: libstdc++/10535

[Wolfgang Bangerth <bangerth@ices.utexas.edu>]

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/