Latest snapshot won't build with --enable-libstdcxx-v3

Latest snapshot won't build with --enable-libstdcxx-v3

[Benjamin Scherrey]

    I'm having really bad luck getting the last two snapshots to build
(I've not tried the others). Specifically, I'm trying to prepare for the
gcc 3 with the new libstdc++ so my code will be ready for the release.
Unfortunately, I can't complete the 'make bootstrap' with the new
snapshot, 20000918. It looks like it dies trying to build libstdc++.

    I'm running linux 2.2.14-5.0 (RedHat 6.2) on an i686 box with
gcc-2.95.2 as my compiler. I configured egcs with '--enable-shared
--enable-libstdcxx-v3' then did a 'make bootstrap'. Is anyone else
getting a successful build?

    thanx & later,

        Ben Scherrey

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Theodore Papadopoulo]

[-- Attachment #1: Type: text/plain, Size: 4662 bytes --]

scherrey@switchco.com said:
>     I'm having really bad luck getting the last two snapshots to build
> (I've not tried the others). Specifically, I'm trying to prepare for
> the gcc 3 with the new libstdc++ so my code will be ready for the
> release. Unfortunately, I can't complete the 'make bootstrap' with the
> new snapshot, 20000918. It looks like it dies trying to build
> libstdc++.

>     I'm running linux 2.2.14-5.0 (RedHat 6.2) on an i686 box with
> gcc-2.95.2 as my compiler. I configured egcs with '--enable-shared
> --enable-libstdcxx-v3' then did a 'make bootstrap'. Is anyone else
> getting a successful build? 


I have the same problem here with a very similar configuration with 
yesterday's cvs.

The bootstrap dies when compiling locale.cc without giving any 
explicit error message because of the redirection of the error 
messages. Why having done that anyway ??? I fill somewhat responsible 
because this redirection was not here before I complained about the 
use of Werror.

> mururoa->tail build.log
> 
/0/robotvis/papadop/src/Compiles/gcc-linux/gcc/g++ -B/0/robotvis/papadop/src/Compiles/gcc-linux/gcc/ -nostdinc++ -L/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstd++-v3/src -L/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstd++-v3/src/.libs -B/net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/bin/ -B/net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/lib/ -isystem /net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/include -DHAVE_CONFIG_H -I. -I../../../../../Cvs/gcc/libstdc++-v3/src -I.. -D_GNU_SOURCE -nostdinc++ -I../../../../../Cvs/gcc/libstdc++-v3 -I../libio -I../../../../../Cvs/gcc/libstdc++-v3/libio -I../../../../../Cvs/gcc/libstdc++-v3/config/cpu/i486 -I../../../../../Cvs/gcc/libstdc++-v3/config/gnu-linux -I/net/home/robotvis/gnu/egcs/include -g -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c ../../../../../Cvs/gcc/libst!
dc++-v3/src/locale.cc -o locale.o >/dev/null 2>&1
make[4]: *** [locale.lo] Error 1
make[4]: Leaving directory `/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstdc++-v3'
make[2]: *** [all-recursive-am] Error 2
make[2]: Leaving directory `/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/0/robotvis/papadop/src/Compiles/gcc-linux'
make: *** [bootstrap] Error 2

Suppressing the redirection of errors gives:

jamaique->/0/robotvis/papadop/src/Compiles/gcc-linux/gcc/g++ -B/0/robotvis/papad
op/src/Compiles/gcc-linux/gcc/ -nostdinc++ -L/0/robotvis/papadop/src/Compiles/gc
c-linux/i686-pc-linux-gnu/libstd++-v3/src -L/0/robotvis/papadop/src/Compiles/gcc
-linux/i686-pc-linux-gnu/libstd++-v3/src/.libs -B/net/home/robotvis/gnu/egcs/i68
6-pc-linux-gnu/bin/ -B/net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/lib/ -isyste
m /net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/include -DHAVE_CONFIG_H -I. -I..
/../../../../Cvs/gcc/libstdc++-v3/src -I.. -D_GNU_SOURCE -nostdinc++ -I../../../
../../Cvs/gcc/libstdc++-v3 -I../libio -I../../../../../Cvs/gcc/libstdc++-v3/libi
o -I../../../../../Cvs/gcc/libstdc++-v3/config/cpu/i486 -I../../../../../Cvs/gcc
/libstdc++-v3/config/gnu-linux -I/net/home/robotvis/gnu/egcs/include -g -O2 -fvt
able-thunks -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-s
trings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sect
ions -g -c ../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc -o locale.o
../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc: In member function `bool std:
:ctype<__wchar_t>::do_is (short 
   unsigned int, __wchar_t) const':
../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc:926: warning: comparison of un
signed expression >= 0 is 
   always true
../../../../../Cvs/gcc/libstdc++-v3/bits/locale_facets.h:420: warning: unreachab
le code at beginning of switch 
   statement
../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc:926: Internal error: Segmentat
ion fault.
   Please submit a full bug report.
   See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

If I have read the list carefully, this might have already been 
fixed... I'll try tonight.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------



[-- Attachment #2: pgp00000.pgp --]
[-- Type: text/plain, Size: 4983 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii



scherrey@switchco.com said:
>     I'm having really bad luck getting the last two snapshots to build
> (I've not tried the others). Specifically, I'm trying to prepare for
> the gcc 3 with the new libstdc++ so my code will be ready for the
> release. Unfortunately, I can't complete the 'make bootstrap' with the
> new snapshot, 20000918. It looks like it dies trying to build
> libstdc++.

>     I'm running linux 2.2.14-5.0 (RedHat 6.2) on an i686 box with
> gcc-2.95.2 as my compiler. I configured egcs with '--enable-shared
> --enable-libstdcxx-v3' then did a 'make bootstrap'. Is anyone else
> getting a successful build? 


I have the same problem here with a very similar configuration with 
yesterday's cvs.

The bootstrap dies when compiling locale.cc without giving any 
explicit error message because of the redirection of the error 
messages. Why having done that anyway ??? I fill somewhat responsible 
because this redirection was not here before I complained about the 
use of Werror.

> mururoa->tail build.log
> 
/0/robotvis/papadop/src/Compiles/gcc-linux/gcc/g++ -B/0/robotvis/papadop/src/Compiles/gcc-linux/gcc/ -nostdinc++ -L/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstd++-v3/src -L/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstd++-v3/src/.libs -B/net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/bin/ -B/net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/lib/ -isystem /net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/include -DHAVE_CONFIG_H -I. -I../../../../../Cvs/gcc/libstdc++-v3/src -I.. -D_GNU_SOURCE -nostdinc++ -I../../../../../Cvs/gcc/libstdc++-v3 -I../libio -I../../../../../Cvs/gcc/libstdc++-v3/libio -I../../../../../Cvs/gcc/libstdc++-v3/config/cpu/i486 -I../../../../../Cvs/gcc/libstdc++-v3/config/gnu-linux -I/net/home/robotvis/gnu/egcs/include -g -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c ../../../../../Cvs/gcc/libst!
dc++-v3/src/locale.cc -o locale.o >/dev/null 2>&1
make[4]: *** [locale.lo] Error 1
make[4]: Leaving directory `/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstdc++-v3'
make[2]: *** [all-recursive-am] Error 2
make[2]: Leaving directory `/0/robotvis/papadop/src/Compiles/gcc-linux/i686-pc-linux-gnu/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/0/robotvis/papadop/src/Compiles/gcc-linux'
make: *** [bootstrap] Error 2

Suppressing the redirection of errors gives:

jamaique->/0/robotvis/papadop/src/Compiles/gcc-linux/gcc/g++ -B/0/robotvis/papad
op/src/Compiles/gcc-linux/gcc/ -nostdinc++ -L/0/robotvis/papadop/src/Compiles/gc
c-linux/i686-pc-linux-gnu/libstd++-v3/src -L/0/robotvis/papadop/src/Compiles/gcc
- -linux/i686-pc-linux-gnu/libstd++-v3/src/.libs -B/net/home/robotvis/gnu/egcs/i68
6-pc-linux-gnu/bin/ -B/net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/lib/ -isyste
m /net/home/robotvis/gnu/egcs/i686-pc-linux-gnu/include -DHAVE_CONFIG_H -I. -I..
/../../../../Cvs/gcc/libstdc++-v3/src -I.. -D_GNU_SOURCE -nostdinc++ -I../../../
../../Cvs/gcc/libstdc++-v3 -I../libio -I../../../../../Cvs/gcc/libstdc++-v3/libi
o -I../../../../../Cvs/gcc/libstdc++-v3/config/cpu/i486 -I../../../../../Cvs/gcc
/libstdc++-v3/config/gnu-linux -I/net/home/robotvis/gnu/egcs/include -g -O2 -fvt
able-thunks -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-s
trings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sect
ions -g -c ../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc -o locale.o
../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc: In member function `bool std:
:ctype<__wchar_t>::do_is (short 
   unsigned int, __wchar_t) const':
../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc:926: warning: comparison of un
signed expression >= 0 is 
   always true
../../../../../Cvs/gcc/libstdc++-v3/bits/locale_facets.h:420: warning: unreachab
le code at beginning of switch 
   statement
../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc:926: Internal error: Segmentat
ion fault.
   Please submit a full bug report.
   See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

If I have read the list carefully, this might have already been 
fixed... I'll try tonight.

- --------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE5x+OVIzTj8qrxOU4RAgLmAJ4npnT/Y5k+xY5gYYhx7JtBSyayiwCgnhsR
ylOcO2mhlUM4rxlKuXUaO3g=
=zYbK
-----END PGP SIGNATURE-----

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Benjamin Kosnik]

> >     I'm having really bad luck getting the last two snapshots to build
> > (I've not tried the others). Specifically, I'm trying to prepare for
> > the gcc 3 with the new libstdc++ so my code will be ready for the
> > release. Unfortunately, I can't complete the 'make bootstrap' with the
> > new snapshot, 20000918. It looks like it dies trying to build
> > libstdc++.

FYI, snapshots that I've tried that have worked:

2000-09-19 
2000-09-10 (last bootstrap)
2000-08-27 (last debuggable)

> messages. Why having done that anyway ??? I fill somewhat responsible 
> because this redirection was not here before I complained about the 
> use of Werror.

it was always there 


> ../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc:926: Internal error: Segmentat
> ion fault.
>    Please submit a full bug report.
>    See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

...quite obviously a compiler bug. It's fixed now

-benjamin

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Theodore Papadopoulo]

bkoz@redhat.com said:
>> messages. Why having done that anyway ??? I fill somewhat responsible 
>> because this redirection was not here before I complained about the 
>> use of Werror.
> it was always there  

But what is the rationale behind it ???

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Benjamin Scherrey]

Benjamin Kosnik wrote:
> 
> > >     I'm having really bad luck getting the last two snapshots to build
> > > (I've not tried the others). Specifically, I'm trying to prepare for
> > > the gcc 3 with the new libstdc++ so my code will be ready for the
> > > release. Unfortunately, I can't complete the 'make bootstrap' with the
> > > new snapshot, 20000918. It looks like it dies trying to build
> > > libstdc++.
> 
> FYI, snapshots that I've tried that have worked:
> 
> 2000-09-19
> 2000-09-10 (last bootstrap)
> 2000-08-27 (last debuggable)

	I don't find a 2000-09-19 anywhere. I tried the latest cvs code and it
dies bulding java/jcf-parse.c. Is there someway to specify getting the
2000-09-19 snapshot out of cvs (I'm new to using the cvs for gcc)?

	thanx & later,

		Ben Scherrey

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Joe Buck]

> bkoz@redhat.com said:
> >> messages. Why having done that anyway ??? I fill somewhat responsible 
> >> because this redirection was not here before I complained about the 
> >> use of Werror.
> > it was always there  
> 
> But what is the rationale behind it ???

I wasn't the person who decided to put in -Werror, but I think it is
a very good idea for libstdc++ to use it.

Warnings produced by the inclusion of system library header files are not
acceptable, because it means that no user of the library can use flags
like -Wall without being distracted by warnings from the system library.
(Old-time Cygnoids are sure to remember how I always used to beat them
up for this - libg++ used to always generate piles of warnings, I'd send
lots of little patches to fix them, and then the next release would
put them all back again).

Putting in -Werror forces the developers to produce warning-free code.

(Now, warnings in files that will never be compiled by library users
aren't a problem, but we currently don't have a way to change the
warning level every time we cross an #include boundary).

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Theodore Papadopoulo]

jbuck@racerx.synopsys.com said:
> I wasn't the person who decided to put in -Werror, but I think it is a
> very good idea for libstdc++ to use it.

> Warnings produced by the inclusion of system library header files are
> not acceptable, because it means that no user of the library can use
> flags like -Wall without being distracted by warnings from the system
> library. (Old-time Cygnoids are sure to remember how I always used to
> beat them up for this - libg++ used to always generate piles of
> warnings, I'd send lots of little patches to fix them, and then the
> next release would put them all back again).

> Putting in -Werror forces the developers to produce warning-free code.

I think that everyone agrees that it is a good idea. Unfortunately, 
it sometimes prevents people (I'm among them) to compile libstc++-v3
because of bugs in their system include file (which sadly is a not so
old glibc) which is bad, and for which we do not have any workaround
currently.

That's too bad, but to encourage more people test the new library it 
was better to remove Werror. It is still there when using
--enable-maintainer-mode IIRC.

But my question was another one.... Certainly I have not been clear 
enough.

I was wondering what was the rationale behind redirecting the 
compiler messages to /dev/null which is exactly the opposite of the 
philosophy exposed above, ie expose the developers  to the messages 
as much as possible!!!

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Benjamin Scherrey]

FYI - Latest CVS source still dies in libstdc++-v3/src/local.cc . I'm stuck until I
can get 2.96 going with libstdc++v3. Has anyone been successful doing this? I was
under the impression that this had/has been working.

    thanx & later,

        Ben Scherrey

Benjamin Kosnik wrote:

> > >     I'm having really bad luck getting the last two snapshots to build
> > > (I've not tried the others). Specifically, I'm trying to prepare for
> > > the gcc 3 with the new libstdc++ so my code will be ready for the
> > > release. Unfortunately, I can't complete the 'make bootstrap' with the
> > > new snapshot, 20000918. It looks like it dies trying to build
> > > libstdc++.
>
> FYI, snapshots that I've tried that have worked:
>
> 2000-09-19
> 2000-09-10 (last bootstrap)
> 2000-08-27 (last debuggable)
> <snip>

>
> > ../../../../../Cvs/gcc/libstdc++-v3/src/locale.cc:926: Internal error: Segmentat
> > ion fault.
> >    Please submit a full bug report.
> >    See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
>
> ....quite obviously a compiler bug. It's fixed now
>
> -benjamin

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Steven King]

On Wed, 20 Sep 2000, Benjamin Scherrey wrote:
> FYI - Latest CVS source still dies in libstdc++-v3/src/local.cc . I'm stuck until I
> can get 2.96 going with libstdc++v3. Has anyone been successful doing this? I was
> under the impression that this had/has been working.

  I was able to bootstrap the Sept 16 CVS (rh 6.2 on i686); but as you noticed,
it appears to have regressed.  A simple hack if you just want to get it to
bootstrap and probably arent going to use the wide IO facilities is

Index: libstdc++-v3/src/locale.cc
===================================================================
RCS file: /cvs/gcc/egcs/libstdc++-v3/src/locale.cc,v
retrieving revision 1.14
diff -c -p -3 -r1.14 locale.cc
*** locale.cc   2000/09/20 08:19:07     1.14
--- locale.cc   2000/09/20 16:28:00
*************** namespace std {
*** 913,919 ****
    bool
    ctype<wchar_t>::
    do_is(mask __m, char_type __c) const
!   { return static_cast<bool>(iswctype(__c, _M_convert_to_wmask(__m))); }

    const wchar_t*
    ctype<wchar_t>::
--- 913,919 ----
    bool
    ctype<wchar_t>::
    do_is(mask __m, char_type __c) const
!   { return static_cast<bool>(iswctype(__c, 0 /* _M_convert_to_wmask(__m) */)); }

    const wchar_t*
    ctype<wchar_t>::         

-- 
Steven King
sxking@uswest.net

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Phil Edwards]

On Wed, Sep 20, 2000 at 05:41:53PM +0200, Theodore Papadopoulo wrote:
> I was wondering what was the rationale behind redirecting the 
> compiler messages to /dev/null which is exactly the opposite of the 
> philosophy exposed above, ie expose the developers  to the messages 
> as much as possible!!!

My understanding is that libtool does this.  Watch carefully as those
files are compiled; each source file is being compiled twice; one PIC and
one non-PIC.  The first goes into the .so, the second goes into the .a.

Output and errors from the first are seen.  Since the second compilation is
(presumably) producing the same warnings/errors as the first, its output
is sunk to keep duplicate noise out of the results.

And as you've seen, when the presence of PIC causes different results,
though, Bad Things happen...

Again, just my own conclusions.  I could easily be wrong.
Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Benjamin Kosnik]

> FYI - Latest CVS source still dies in libstdc++-v3/src/local.cc . I'm stuck until I
> can get 2.96 going with libstdc++v3. Has anyone been successful doing this? I was
> under the impression that this had/has been working.

This is what I got working last night: 

gcc/ChangeLog
2000-09-19  Jim Wilson  <wilson@cygnus.com>

        * config/ia64/crtbegin.asm (__dso_handle): Delete use of
        HAVE_GAS_HIDDEN macro.
   Working revision:	1.7833

gcc/cp/ChangeLog
2000-09-18  Mark Mitchell  <mark@codesourcery.com>

        * decl.c (start_function): Robustify.
   Working revision:	1.2005


I'm working on a system with corrected glibc headers though, so perhaps
this makes a difference (I doubt it.)


FYI: 

In any case, I find it quite useful to archive away sources to a working
gcc subdirectory. I usually update once a week, and archive the updates
the bootstrap. Then I can fall back onto older gcc versions if current CVS
is unusable.

-benjamin

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Benjamin Scherrey]

That got the compiler to build and install but there are still problems. It appears that
libstdc++ v3 has been installed correctly in /usr/local/lib. I can compile my test code
but the link fails with the stream stuff. My test code exercises <string>, <sstream>,
and <iostream>.

    thanx & later,

        Ben Scherrey

Steven King wrote:

> On Wed, 20 Sep 2000, Benjamin Scherrey wrote:
> > FYI - Latest CVS source still dies in libstdc++-v3/src/local.cc . I'm stuck until I
> > can get 2.96 going with libstdc++v3. Has anyone been successful doing this? I was
> > under the impression that this had/has been working.
>
>   I was able to bootstrap the Sept 16 CVS (rh 6.2 on i686); but as you noticed,
> it appears to have regressed.  A simple hack if you just want to get it to
> bootstrap and probably arent going to use the wide IO facilities is

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Benjamin Kosnik]

On Wed, 20 Sep 2000, Benjamin Scherrey wrote:

> That got the compiler to build and install but there are still problems. It appears that
> libstdc++ v3 has been installed correctly in /usr/local/lib. I can compile my test code
> but the link fails with the stream stuff. My test code exercises <string>, <sstream>,
> and <iostream>.

what's the link failure?

what's the output of gcc -v -H?

-benjamin

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Benjamin Scherrey]

Attached is the source/compiler output. Apparently it finds all the libraries its looking for
but not the required symbols. Dunno why that is.

    thanx & later,

        Ben Scherrey

Benjamin Kosnik wrote:

> On Wed, 20 Sep 2000, Benjamin Scherrey wrote:
>
> > That got the compiler to build and install but there are still problems. It appears that
> > libstdc++ v3 has been installed correctly in /usr/local/lib. I can compile my test code
> > but the link fails with the stream stuff. My test code exercises <string>, <sstream>,
> > and <iostream>.
>
> what's the link failure?
>
> what's the output of gcc -v -H?
>
> -benjamin

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Benjamin Scherrey]

Possible Repost - This message didn't seem to make it to the gcc list.

Attached is the source/compiler output. Apparently it finds all the
libraries its looking for
but not the required symbols. Dunno why that is.

    thanx & later,

        Ben Scherrey

Benjamin Kosnik wrote:

> On Wed, 20 Sep 2000, Benjamin Scherrey wrote:
>
> > That got the compiler to build and install but there are still problems. It appears that
> > libstdc++ v3 has been installed correctly in /usr/local/lib. I can compile my test code
> > but the link fails with the stream stuff. My test code exercises <string>, <sstream>,
> > and <iostream>.
>
> what's the link failure?
>
> what's the output of gcc -v -H?
>
> -benjamin
//
//	Assign.cpp	-	Tests implementation of assignment operator.
//

#include <iostream>
#include <string>
#include <sstream>

using namespace std;

class Test
{

public:

	Test( const int t = 0 ) : i(t) 
	{
		cout << "Test default constructor." << endl;
	}

	Test( const Test& t )
	{
		cout << "Test copy constructor." << endl;
		i = t.i;
	}

	Test& operator=( const Test& t )
	{
		cout << "Test assignment operator." << endl;
		i = t.i;
		return *this;
	}

	string print( void ) const
	{
	    stringstream s;
	    s << "i = " << i;
/*
        char buf[10];
        itoa( i, buf, 10 );
		string s = "i = ";
		s += buf;
*/		
		return s.str();
	}

private:

	int i;
	
};

class Derived : public Test
{

public:

	Derived( int t1 = 0, int t2 = 0 ) : Test( t1 ), j( t2 )
	{
		cout << "Derived default constructor." << endl;
	}

	Derived( const Derived& d ) : Test( d )
	{
		cout << "Derived copy constructor." << endl;
		j = d.j;
	}

	Derived& operator=( const Derived& d )
	{
		cout << "Derived assignment operator." << endl;
		j = d.j;
        Test::operator=( d );
        return *this;
	}
	
	string print( void ) const
	{

/*
        char buf[ 10 ];
        itoa( j, buf, 10 );
		string s = "j = ";
		s += buf;
		s += " - ";
		s += Test::print();
*/
        stringstream s;
	    s << "j = " << j << " - " << Test::print();		
		return s.str();
	}

private:

	int j;
};

int main( void )
{
	Derived D1( 5,5 );
	Derived D2( 7,7 );

	cout << "D1 = " << D1.print() << endl;
	cout << "D2 = " << D2.print() << endl;

	cout << "D1 = D2" << endl;
	D1 = D2;

	cout << "D1 = " << D1.print() << endl;
	cout << "D2 = " << D2.print() << endl;

	return 0;
}

// eof( Assign.cpp )

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Marc Espie]

In article < 200009201530.IAA14094@racerx.synopsys.com > you write:
>Warnings produced by the inclusion of system library header files are not
>acceptable, because it means that no user of the library can use flags
>like -Wall without being distracted by warnings from the system library.
>(Old-time Cygnoids are sure to remember how I always used to beat them
>up for this - libg++ used to always generate piles of warnings, I'd send
>lots of little patches to fix them, and then the next release would
>put them all back again).


>Putting in -Werror forces the developers to produce warning-free code.

I'd concur.
Not only that, but some people routinely compile some critical code with
a large list of warnings, plus -Werror... (the OpenBSD kernel, for instance).

so yes, having warnings in header code is a complete no-no.

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Marc Espie]

In article < 200009201541.e8KFfr711897@mururoa.inria.fr > you write:
>
>jbuck@racerx.synopsys.com said:
>> I wasn't the person who decided to put in -Werror, but I think it is a
>> very good idea for libstdc++ to use it.
>
>> Warnings produced by the inclusion of system library header files are
>> not acceptable, because it means that no user of the library can use
>> flags like -Wall without being distracted by warnings from the system
>> library. (Old-time Cygnoids are sure to remember how I always used to
>> beat them up for this - libg++ used to always generate piles of
>> warnings, I'd send lots of little patches to fix them, and then the
>> next release would put them all back again).

>> Putting in -Werror forces the developers to produce warning-free code.

>I think that everyone agrees that it is a good idea. Unfortunately, 
>it sometimes prevents people (I'm among them) to compile libstc++-v3
>because of bugs in their system include file (which sadly is a not so
>old glibc) which is bad, and for which we do not have any workaround
>currently.

In my opinion, that should only be more incentive to put pressure on the
guys behind that library to fix the problem.  With all software development
I've seen, putting `work-arounds' in software under development is a very
good receipe to make sure bugs are Not fixed in time for the next release,
as they're not seen to be critical...

From one point of view, glibc is somewhat `special'.

From another point of view, it should be just another system library on
a random system... first, because there is more to gcc than the glibc
(but this is political).  Second, because having to do gcc development 
in lock-step with glibc is a sure receipe for disaster.  The looser 
coupling, the better (now this is a technical issue).

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Chris G. Demetriou]

espie@quatramaran.ens.fr (Marc Espie) writes:
> >Putting in -Werror forces the developers to produce warning-free code.
> 
> I'd concur.
> Not only that, but some people routinely compile some critical code with
> a large list of warnings, plus -Werror... (the OpenBSD kernel, for instance).
> 
> so yes, having warnings in header code is a complete no-no.

as an aside about this:

there are a lot of people out there who e.g. use -Wall and -Werror
(e.g. at least NetBSD as well).

For them, the addition of warnings which are in fact spurious,
i.e. correct code that's not bad style, is Really Bad.

For instance, the fact that -Wuninitialized often returns (or has
historically returned) false positives has caused NetBSD to _remove
it_ from NetBSD gcc's "-Wall".  Personally, I find that unfortunate,
because i'd like -Wall to be -Wall everywhere, and I'd like it to
include -Wuninitialized... but i'd like -Wuninitialized to only warn
if it knows there's a problem.  (maybe somebody should do a
-Wuninitialized=2 like -Wformat...)

If there's some bad style that you really want to force people to fix
(e.g. bad parenthesization) that's one thing, but spurious warnings
cause by compiler confusion are Really Bad and make many people's
lives harder.


(This post, plus something I saw earlier about adding warnings if the
compiler can't invoke certain optimizations because of complexity,
made me feel inclined to pipe up about this.)



cgd

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Magnus Fromreide]

The one most annoying default-on warning I have seen is
-Wctor-dtor-privacy - I can see several good reasons to have only private
constructors or destructors without having gcc pester me about it unless I
try to use them from the wrong scope.

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Gabriel Dos Reis]

Magnus Fromreide <magfr@lysator.liu.se> writes:

| The one most annoying default-on warning I have seen is
| -Wctor-dtor-privacy - I can see several good reasons to have only private
| constructors or destructors without having gcc pester me about it unless I
| try to use them from the wrong scope.

I concur.

-- Gaby
CodeSourcery, LLC                             http://www.codesourcery.com

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Joern Rennecke]

> For instance, the fact that -Wuninitialized often returns (or has
> historically returned) false positives has caused NetBSD to _remove

It still does.  In fact, a number of the warning 'fixes' that went into
gcc recently have added spurious initializations to paper over spurious
warnings.

Re: Latest snapshot won't build with --enable-libstdcxx-v3

[Brad Lucier]

Chris G. Demetriou wrote:

> If there's some bad style that you really want to force people to fix
> (e.g. bad parenthesization) that's one thing, but spurious warnings
> cause by compiler confusion are Really Bad and make many people's
> lives harder.
> 
> (This post, plus something I saw earlier about adding warnings if the
> compiler can't invoke certain optimizations because of complexity,
> made me feel inclined to pipe up about this.)

Well, as the person who proposed the -Wdisabled-optimization
warning, let me say that I'm proposing that it *not* be invoked
by any "group" warning flag like -Wall.  You don't claim that
it is, but readers might (reasonably, but falsely) infer that
from what you wrote.

I'd just like to have this optimization information so I can change the
generated C code I'm handing to gcc if I have to.

Brad Lucier