This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error


Rainer Orth wrote:
Tobias Burnus<burnus@net-b.de> writes:
Rainer Orth wrote:
While the build completed with the patch I've posted, fortran testing
for the non-default multilib is completely broken, e.g.
That's in a way the a duplicate of PR 46516. Or at least the solution is
I don't think so: this seems to be an issue finding libgfortran.spec at
compile time (which seems to work for me)

No, finding libgfortran.spec at compile time works - it is all about finding it at run time.


while my issue is about
finding the right (64-bit) libgcc_s.so.1 at runtime, due to a bug in the
construction of LD_LIBRARY_PATH in the testsuite.  This worked before
and is broken now, due to the libquadmath patch.

I am not sure the bug is the same, but they are related. Both are about finding the .spec file at run time; once for the installed system and once for the test-suite run. My plan is first to fix the first issue, namely where the compiler searches for the library and then to revisit the test suite issue.


The changes made can be shown via:
   svn diff -r166824:166825 gcc/testsuite/lib/gfortran.exp

The changes are needed if the compiler is not installed, i.e. the libraries are only in the build directory. In this case "gfortran" (the driver) needs to be able to find the libgfortran.spec file based on the passed -L<dir>. The patch (cf. svn diff) is doing this, but seems to break the test suite in some cases.

Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]