Re: Modify -mabi=64 C++ Testing

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Jeffrey Oldham <oldham@codesourcery.com>
 > 
 > On Tue, Jun 05, 2001 at 07:38:56PM -0400, Kaveh R. Ghazi wrote:
 > >  > From: Jeffrey Oldham <oldham@codesourcery.com>
 > >  > 
 > >  > On Sun, Jun 03, 2001 at 08:41:25PM -0400, Kaveh R. Ghazi wrote:
 > >  > >  > From: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE> 
 > >  > >  > 
 > >  > >  > Jeffrey Oldham writes:
 > >  > >  > 
 > >  > >  > > > Unfortunately, this patch has just the opposite effect for me ;-)
 > >  > >  > > > Before it went it, I could successfully test both N32 and N64 ABIs
 > >  > >  > > > on IRIX 6.2 and 32-bit and 64-bit on Solaris 8.  I'm using command
 > >  > >  > > > lines like this:
 > >  > >  > > > 
 > >  > >  > > >     make RUNTESTFLAGS='--target_board "unix{,-mabi=64}"' check
 > >  > >  > > > or
 > >  > >  > > >     make RUNTESTFLAGS='--target_board "unix{,-m64}"' check
 > >  > >  > > 
 > >  > >  > > How should -mabi=64 tests be run?  I was using
 > >  > >  > > 
 > >  > >  > >       make -k RUNTESTFLAGS="--tool_opts '-mabi=64'" check-g++
 > >  > >  > 
 > >  > >  > This should work to specify a single alternative option.  To run the
 > >  > >  > testsuite with several different options, you need the variant I use,
 > >  > >  > which
 > >  > >  > is documented in the FAQ:
 > >  > >  > 
 > >  > >  >         http://gcc.gnu.org/fom_serv/cache/21.html
 > >  > >  > 
 > >  > >  > So both variants need to continue working.
 > >  > >  >         Rainer
 > >  > > 
 > >  > > So what was the resolution of this problem?  I'm having the same issue
 > >  > > Rainer had using the --target_board option, as shown here in the
 > >  > > following test results on irix6.2:
 > >  > > http://gcc.gnu.org/ml/gcc-testresults/2001-06/msg00071.html
 > >  > > 
 > >  > > I think most of the g++ and libstdc++-v3 tests failures with -mabi=64
 > >  > > I'm seeing are because of this problem.
 > >  > 
 > >  > I just received approval for the patch, which is now committed.  I
 > >  > sent a carbon copy of the patch submission email to you.  I hope this
 > >  > resolves the problem.  Please let me know if it does not.
 > > 
 > > Unfortunately its not working.  The following two links demonstrate
 > > the before and after effects.
 > > 
 > > http://gcc.gnu.org/ml/gcc-testresults/2001-06/msg00101.html
 > > http://gcc.gnu.org/ml/gcc-testresults/2001-06/msg00124.html
 > > 
 > > In the first case, most of the -mabi=64 g++ tests fail to *compile*
 > > because they cannot find the -mabi=64 libstdc++, the regular g++ tests
 > > look good.
 > > 
 > > In the second case, the -mabi=64 cases seem ok, but the regular g++
 > > tests fail to *execute*.
 > > 
 > > There is nothing useful in the g++.log file to indicate why the tests
 > > all fail.  No error message, just a failure.
 > 
 > We need more information to know what is happening.  What command
 > are you using to run the tests?  What is in the g++.log file?  What
 > information is revealed when running a compilation for a failing
 > test by hand?  Are the execution test failures caused by
 > incorrectly specifying where shared libraries are located?

Sorry I couldn't reply earlier.  Here is the info:

When I run the tests, I use "make -k check", however I also set the
environment variable RUNTESTFLAGS to "--target_board 'unix{-mabi=64,}'"
Nothing else special.

Picking one test at random, the g++.log file shows only this:
 > PASS: g++.benjamin/tem06.C (test for excess errors)
 > spawn [open ...]
 > FAIL: g++.benjamin/tem06.C  Execution test

Its annoying that it doesn't show any messages/stderr or how it tried
to invoke it.

When I run g++-benjamin-tem06-C.exe by hand I get:

  742:./g++-benjamin-tem06-C.exe: rld: Fatal Error: Cannot
  Successfully map soname 'libstdc++.so.4' under any of the filenames
  /usr/lib32/libstdc++.so.4:/usr/lib32/internal/libstdc++.so.4:/lib32/libstdc++.so.4:/opt/lib32/libstdc++.so.4:/usr/lib32/libstdc++.so.4.4:/usr/lib32/internal/libstdc++.so.4.4:/lib32/libstdc++.so.4.4:/opt/lib32/libstdc++.so.4.4:

If I set LD_LIBRARY_PATH to the directory containing the N32
libstdc++.so.4, I get a complaint about missing libgcc_s.so.0.

In the end, I can run the test by hand if I set LD_LIBRARY_PATH to the
following:

<builddir>/mips-sgi-irix6.2/libstdc++-v3/src/.libs/:<builddir>/gcc

(where <builddir> is the toplevel build dir in which I built gcc.)

We need to ensure that the testsuite knows how to link these binary
tests so that they can pick up the right shared lib.  Somehow this
works when the testsuite runs the mabi=64 tests, but not for the
regular (N32) tests.

It would be really nice if the invocation line and the resulting
errors would appear in the logfile.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions