From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer Orth To: bkoz@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: libstdc++/2841 Date: Fri, 25 May 2001 12:26:00 -0000 Message-id: <20010525192603.20178.qmail@sourceware.cygnus.com> X-SW-Source: 2001-05/msg00817.html List-Id: The following reply was made to PR libstdc++/2841; it has been noted by GNATS. From: Rainer Orth To: Benjamin Kosnik 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