Re: libstdc++/2841

Re: libstdc++/2841

[Rainer Orth]

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

From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: bkoz@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
        "Kaveh R. Ghazi"  <ghazi@caip.rutgers.edu>
Subject: Re: libstdc++/2841
Date: Wed, 6 Jun 2001 14:00:36 +0200 (MEST)

 bkoz@gcc.gnu.org writes:
 
 > Synopsis: -static in libstdc++ v3 dejagnu testsuite causes linking to fail
 > 
 > State-Changed-From-To: feedback->closed
 > State-Changed-By: bkoz
 > State-Changed-When: Tue Jun  5 18:31:09 2001
 > State-Changed-Why:
 >     I'd like to fix this, as I believe the original problem is fixed. There are lingering bugs in the testsuite, but I'd appreciate it if you'd open new CR's for them...
 
 Part of is, yes.  But as Kaveh Ghazi reported in
 
 	http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00261.html
 
 you still get unexpected behaviour since you need to run make check for
 non-default multilibs manually in
 $(top_builddir)/$(multilibsubdir)/libstdc++-v3, just invoking make check
 with the appropriate RUNTESTFLAGS (either e.g. --tool_opts '-mabi=64' or
 --target_board "unix{-mabi=64}") will still (seem to) fail, since that is
 run in $(top_builddir)/libstdc++-v3, thus finding the wrong libstdc++-v3
 dir.
 
 	Rainer
 
 -----------------------------------------------------------------------------
 Rainer Orth, Faculty of Technology, Bielefeld University
 
 Email: ro@TechFak.Uni-Bielefeld.DE

Re: libstdc++/2841

[bkoz]

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

From: bkoz@gcc.gnu.org
To: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, ro@TechFak.Uni-Bielefeld.DE
Cc:  
Subject: Re: libstdc++/2841
Date: 6 Jun 2001 01:31:09 -0000

 Synopsis: -static in libstdc++ v3 dejagnu testsuite causes linking to fail
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: bkoz
 State-Changed-When: Tue Jun  5 18:31:09 2001
 State-Changed-Why:
     I'd like to fix this, as I believe the original problem is fixed. There are lingering bugs in the testsuite, but I'd appreciate it if you'd open new CR's for them...
     
     thanks,
     benjamin
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2841&database=gcc

Re: libstdc++/2841

[Rainer Orth]

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

From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2841
Date: Fri, 25 May 2001 21:21:32 +0200 (MEST)

 Benjamin Kosnik writes:
 
 > > I'll probably retry on a multilibbed configuration or two
 > > (sparcv9-sun-solaris2.8, mips-sgi-irix6.2), to make sure the patch can cope
 > > with the different subdirectory depth there.
 > 
 > ok. Please let me know when I can close this bug report.
 
 The sparcv9-sun-solaris2.8 make check (for -m64, the default) is now on
 it's way since libstdc++/2568 seems to be fixable as just reported.
 
 I'll report on the second run with RUNTESTFLAGS='--target_board "unix{-m32}"'
 when the first one is done.
 
 IRIX 6.2 -m64 looks pretty much broken: running with
 RUNTESTFLAGS='--target_board "unix{-mabi=64}"' causes all libstdc++ v3
 compilations to fail: the problem is that despite the -mabi=64 argument,
 make check is still run in mips-sgi-irix6.2/libstdc++-v3/testsuite:
 
 spawn /vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/gcc/g++ -B/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/gcc/ -nostdinc++ -L/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/libstdc++-v3/src -L/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/libstdc++-v3/src/.libs -B/vol/gcc/mips-sgi-irix6.2/bin/ -B/vol/gcc/mips-sgi-irix6.2/lib/ -isystem /vol/gcc/mips-sgi-irix6.2/include -ggdb3 -DDEBUG_ASSERT -ffunction-sections -fdata-sections -nostdinc++ -I/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/libstdc++-v3 /include -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/std -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/c_std -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/libsupc++ -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/libio -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-!
 branch-dist/libstdc++-v3/testsuite -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/backwards -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/ext /amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/testsuite/17_intro/header_cassert.cc -DDEBUG_ASSERT -lm -mabi=64 -o ./header_cassert 
 ld64: FATAL 12: Expecting 64-bit objects: /vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/libstdc++-v3/src/.libs/libstdc++.so is n32.
 collect2: ld returned 4 exit status
 compiler exited with status 1
 output is:
 ld64: FATAL 12: Expecting 64-bit objects: /vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/libstdc++-v3/src/.libs/libstdc++.so is n32.
 collect2: ld returned 4 exit status
 
 FAIL: 17_intro/header_cassert.cc (test for excess errors)
 
 The obvious problem is that though dejagnu passes the -mabi=64, the default
 (i.e. N32) libstdc++-v3 lib directory is still searched.
 
 The obivous first fix is to (manually for now) run make check in
 mips-sgi-irix6.2/mabi=64/libstdc++-v3/testsuite:
 
 spawn /vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/gcc/g++ -B/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/gcc/ -nostdinc++ -L/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/mabi=64/libstdc++-v3/src -L/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/mabi=64/libstdc++-v3/src/.libs -B/vol/gcc/mips-sgi-irix6.2/bin/ -B/vol/gcc/mips-sgi-irix6.2/lib/ -isystem /vol/gcc/mips-sgi-irix6.2/include -mabi=64 -ggdb3 -DDEBUG_ASSERT -ffunction-sections -fdata-sections -nostdinc++ -I/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips -sgi-irix6.2/mabi=64/libstdc++-v3/include -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/std -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/c_std -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/libsupc++ -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/libio -I/amnt/zacateca!
 s/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/testsuite -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/backwards -I/amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/ext /amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/testsuite/17_intro/header_cassert.cc -DDEBUG_ASSERT -lm -o ./header_cassert 
 ld64: WARNING 84: /vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/mabi=64/libstdc++-v3/src/.libs/libstdc++.so is not used for resolving any symbol.
 ld64: WARNING 127: Two shared objects with the same soname, /usr/lib64/mips3/libm.so and /usr/lib64/libm.so, have been been linked. This is probably due to a missing -L specification. Ignoring the latter.
 output is:
 ld64: WARNING 84: /vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/mabi=64/libstdc++-v3/src/.libs/libstdc++.so is not used for resolving any symbol.
 ld64: WARNING 127: Two shared objects with the same soname, /usr/lib64/mips3/libm.so and /usr/lib64/libm.so, have been been linked. This is probably due to a missing -L specification. Ignoring the latter.
 
 PASS: 17_intro/header_cassert.cc (test for excess errors)
 spawn [open ...]
 FAIL: 17_intro/header_cassert.cc execution test
 
 Here the link succeeds, but the execution fails.  This error doesn't show
 up in the log, but on /dev/tty instead:
 
 2463:./operators: rld: Fatal Error: Cannot Successfully map soname 'libgcc_s_mabi=64.so.0' under any of the filenames ./libgcc_s_mabi=64.so.0:/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/mabi=64/libstdc++-v3/../../gcc/libgcc_s_mabi=64.so.0:/vol/gcc/obj/gcc-3.0-20010523/6.2-gcc/mips-sgi-irix6.2/mabi=64/libstdc++-v3/src/.libs/libgcc_s_mabi=64.so.0:/usr/lib64/libgcc_s_mabi=64.so.0:/usr/lib64/internal/libgcc_s_mabi=64.so.0:/lib64/libgcc_s_mabi=64.so.0:/opt/lib64/libgcc_s_mabi=64.so.0:
 
 This is due to an abomination of the IRIX 6 (and Tru64 UNIX, which are both
 of MIPS heritage) runtime linker, which log errors to /dev/tty by default,
 instead of using stderr.
 
 The IRIX 6 runtime linker rld can be forced to use stderr instead with
 _RLD_ARGS='-log /dev/fd/2' in the environment (I had forgotten this for
 this manual make check invokation), for the Tru64 UNIX loader, the
 corresponding magic spell is _RLD_ARGS=-log_stderr.
 
 Anyway, just as I feared libgcc_s_mabi=64.so.0 isn't found since the
 relative path from the toplevel libstdc++-v3 to gcc where libgcc_s*.so.0
 are located (../../gcc) is ok for the default multilib, but wrong for the
 others (like -mabi=64 in this case): they all need another .. :-)
 
 Regards.
 
 	Rainer
 
 -----------------------------------------------------------------------------
 Rainer Orth, Faculty of Technology, Bielefeld University
 
 Email: ro@TechFak.Uni-Bielefeld.DE

Re: libstdc++/2841

[Rainer Orth]

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

From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2841
Date: Wed, 23 May 2001 23:17:28 +0200 (MEST)

 Benjamin Kosnik writes:
 
 > > Indeed, works like a charm.  I had manually installed the missing libm.a on
 > > the V5.1 test machine last night, with pretty good results, and just
 > > retried with the updated libstdc++-v3-dg.exp: the results are identical :-)
 > 
 > excellent. BTW your results for OSF look pretty respectable.
 
 Indeed, and it's not even my work :-)  While I complained before that
 libstdc++ v3 wouldn't compile on Tru64 V4.0F or V5.1, yesterday night I
 started with a fresh tree and incorporated the fixes I needed to get it to
 bootstrap on V5.1 one by one.  After a couple of known fixes for V5.1 (long
 double support primarily) went in, I could build libstdc++ v3 even without
 my OSF port.  I'm about to check the testsuite failures individually and
 find out if my port improves them or breaks more tests.  I'll post to
 libstdc++ when I'm ready.
 
 > > I'll probably retry on a multilibbed configuration or two
 > > (sparcv9-sun-solaris2.8, mips-sgi-irix6.2), to make sure the patch can cope
 > > with the different subdirectory depth there.
 > 
 > ok. Please let me know when I can close this bug report.
 
 Sure: the IRIX 6.2 machine, an 2 CPU R8000 Power Challenge/L, is incredibly
 slow (still building the stage 2 compiler), and running the testsuite there
 is even slower since I'll run it for both the N32 and N64 ABIs.
 
 64-bit Solaris 8 just aborted in gen-num-limits (this worked on 20010402);
 will have to investigate what's wrong there.
 
 	Rainer
 
 -----------------------------------------------------------------------------
 Rainer Orth, Faculty of Technology, Bielefeld University
 
 Email: ro@TechFak.Uni-Bielefeld.DE

Re: libstdc++/2841

[Benjamin Kosnik]

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

From: Benjamin Kosnik <bkoz@redhat.com>
To: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2841
Date: Wed, 23 May 2001 14:07:28 -0700 (PDT)

 > Indeed, works like a charm.  I had manually installed the missing libm.a on
 > the V5.1 test machine last night, with pretty good results, and just
 > retried with the updated libstdc++-v3-dg.exp: the results are identical :-)
 
 excellent. BTW your results for OSF look pretty respectable.
 
 > I'll probably retry on a multilibbed configuration or two
 > (sparcv9-sun-solaris2.8, mips-sgi-irix6.2), to make sure the patch can cope
 > with the different subdirectory depth there.
 
 ok. Please let me know when I can close this bug report.

Re: libstdc++/2841

[Rainer Orth]

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

From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2841
Date: Wed, 23 May 2001 18:50:32 +0200 (MEST)

 Benjamin Kosnik writes:
 
 > have you tried CVS/branch gcc to see if setting ld_library_path works for 
 > you?
 
 I'm not sure what you mean here?  I didn't have to set ld_library_path
 (either in the dejagnu testsuite or LD_LIBRARY_PATH in the environment) at
 all to have the make check to succeed.  In fact, I've just verified (by
 running the first compilation in libstdc++-v3.log manually) that the shared
 libgcc_s.so.0 is used in fact, and if I just try to run the resulting
 ./header_cassert in the shell, it fails since it cannot find that library
 (I don't have an installed gcc 3.0 yet, so the only place that library can
 be found is in the build tree.)  So at least that part of the testsuite
 change works as expected.  I'll learn about the rest (i.e. finding
 libstdc++.so.3) when I've bootstrapped and checked the other platforms
 where building shared libraries do work.
 
 	Rainer
 
 -----------------------------------------------------------------------------
 Rainer Orth, Faculty of Technology, Bielefeld University
 
 Email: ro@TechFak.Uni-Bielefeld.DE

Re: libstdc++/2841

[Rainer Orth]

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

From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: bkoz@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2841
Date: Wed, 23 May 2001 17:37:36 +0200 (MEST)

 bkoz@gcc.gnu.org writes:
 
 >     Actually, I think I just fixed this.
 >     
 >     Can you try this patch and let me know if it resolves your problem:
 >     
 >     http://gcc.gnu.org/ml/libstdc++/2001-05/msg00254.html
 
 Indeed, works like a charm.  I had manually installed the missing libm.a on
 the V5.1 test machine last night, with pretty good results, and just
 retried with the updated libstdc++-v3-dg.exp: the results are identical :-)
 
 I'll probably retry on a multilibbed configuration or two
 (sparcv9-sun-solaris2.8, mips-sgi-irix6.2), to make sure the patch can cope
 with the different subdirectory depth there.
 
 Thanks alot for the quick fix.
 
 	Rainer
 
 -----------------------------------------------------------------------------
 Rainer Orth, Faculty of Technology, Bielefeld University
 
 Email: ro@TechFak.Uni-Bielefeld.DE

Re: libstdc++/2841

[Benjamin Kosnik]

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

From: Benjamin Kosnik <bkoz@redhat.com>
To: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2841
Date: Wed, 23 May 2001 09:40:26 -0700 (PDT)

 have you tried CVS/branch gcc to see if setting ld_library_path works for 
 you?
 
 -benjamin
 
 > I had them working some time in the past, but cannot find the old build
 > trees anymore, so I don't really know what changed since then.  It may well
 > be related to one of Alexandre's recent checkins of more recent libtool
 > versions.  I'll dig around a bit and report what I find.
 
 cool thanks

Re: libstdc++/2841

[Rainer Orth]

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

From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: bkoz@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2841
Date: Wed, 23 May 2001 17:32:52 +0200 (MEST)

 bkoz@gcc.gnu.org writes:
 
 >     FYI to get shared libraries working/building, you'll have to do top-level work to the libtool cxx files (ltcf-cxx.sh) to add support for Tru64. Alexandre Oliva is a good person to talk to about this, as well as Loren James Rittle <rittle@latour.rsch.comm.mot.com>, who added support for BSD.
 
 I had them working some time in the past, but cannot find the old build
 trees anymore, so I don't really know what changed since then.  It may well
 be related to one of Alexandre's recent checkins of more recent libtool
 versions.  I'll dig around a bit and report what I find.
 
 	Rainer
 
 -----------------------------------------------------------------------------
 Rainer Orth, Faculty of Technology, Bielefeld University
 
 Email: ro@TechFak.Uni-Bielefeld.DE

Re: libstdc++/2841

[bkoz]

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

From: bkoz@gcc.gnu.org
To: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, ro@TechFak.Uni-Bielefeld.DE
Cc:  
Subject: Re: libstdc++/2841
Date: 23 May 2001 01:28:21 -0000

 Synopsis: -static in libstdc++ v3 dejagnu testsuite causes linking to fail
 
 State-Changed-From-To: analyzed->feedback
 State-Changed-By: bkoz
 State-Changed-When: Tue May 22 18:28:21 2001
 State-Changed-Why:
     Actually, I think I just fixed this.
     
     Can you try this patch and let me know if it resolves your problem:
     
     http://gcc.gnu.org/ml/libstdc++/2001-05/msg00254.html
     
     thanks again,
     benjamin
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2841&database=gcc

Re: libstdc++/2841

[bkoz]

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

From: bkoz@gcc.gnu.org
To: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
  ro@TechFak.Uni-Bielefeld.DE
Cc:  
Subject: Re: libstdc++/2841
Date: 23 May 2001 00:40:33 -0000

 Synopsis: -static in libstdc++ v3 dejagnu testsuite causes linking to fail
 
 Responsible-Changed-From-To: unassigned->bkoz
 Responsible-Changed-By: bkoz
 Responsible-Changed-When: Tue May 22 17:40:33 2001
 Responsible-Changed-Why:
     responsible
 State-Changed-From-To: open->analyzed
 State-Changed-By: bkoz
 State-Changed-When: Tue May 22 17:40:33 2001
 State-Changed-Why:
     I'm taking this.
     
     Can you please send me a patch that includes your modifications for ld_library_path?
     
     Thanks this was a very clear bug report to understand.
     
     FYI to get shared libraries working/building, you'll have to do top-level work to the libtool cxx files (ltcf-cxx.sh) to add support for Tru64. Alexandre Oliva is a good person to talk to about this, as well as Loren James Rittle <rittle@latour.rsch.comm.mot.com>, who added support for BSD.
     
     thanks,
     benjamin
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2841&database=gcc