Re: libstdc++/2841

[Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>]

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