This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Re-enable bi-arch sparc on Solaris 7 and above
- To: Brad Lucier <lucier at math dot purdue dot edu>
- Subject: Re: Re-enable bi-arch sparc on Solaris 7 and above
- From: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>
- Date: 28 May 2001 21:52:24 +0200
- Cc: aoliva at redhat dot com, gcc-patches at gcc dot gnu dot org
- References: <200105202117.QAA09121@zakon.math.purdue.edu>
Brad Lucier <lucier@math.purdue.edu> writes:
> A 3.0 bootstrap on sparc-sun-solaris2.8 gets a good comparison,
> but fails with the same error.
>
> If I search for a c++config.h file, I find
>
> ./objdir/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/include/bits/c++config.h
>
> but there is no sparcv7 (or just sparc) include directory that includes
> the file.
I didn't have any of those problems, instead bootstraps of gcc 3.0
20010523 without and with Alexandre's patch completed successfully and with
no testsuite regressions.
Testsuite results for the first case are at
http://gcc.gnu.org/ml/gcc-testresults/2001-05/msg00654.html
With the bi-arch patch:
http://gcc.gnu.org/ml/gcc-testresults/2001-05/msg00655.html
Same configuration, but testing the 64-bit compiler (with
RUNTESTFLAGS='--target_board "unix{-m64}"'):
http://gcc.gnu.org/ml/gcc-testresults/2001-05/msg00656.html
I'll investigate the differences between the latter two (i.e. -m32 and
-m64), comparing with bi-arch sparcv9-sun-solaris2.8 results and report
what I find.
At least the libstdc++ failures are due to the fact that the current
dejagnu v3 framework doesn't support testing multilibbed libraries.
With the above RUNTESTFLAGS, it tries to run the testsuite in
sparc-sun-solaris2.8/libstdc++-v3/testsuite with -m64, but pointing
LD_LIBRARY_PATH to ../src/.libs, the directory with the -m32 libs, which
must fail.
If I manually run make check (without any RUNTESTFLAGS) in
sparc-sun-solaris2.8/sparcv9/libstdc++-v3 (i.e. the correct multilib
subdir), most (all?) compilations succeed, but the tests wont run since
libgcc_s.so.0 cannot be found (it is searched in $(srcdir)/../gcc, missing
one ../ for non-default multilib subdirs).
I haven't further investigated where to fix this.
Given all this, I'd nonetheless say it's pretty save to enable 32x64
bi-arch again, since the plain 32-bit compiler is completely unaffected.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
Email: ro@TechFak.Uni-Bielefeld.DE