------- Comment #8 from rob1weld at aol dot com 2009-01-27 16:18 ------- (In reply to comment #4) > (In reply to comment #3) > > This is not so much an error in Fortran than it is an error in the > > scripting and it's ability to add it's own LD_LIBRARY_PATH components. > No. The current linking scheme links to the just-built libgfortran, not to > the system libgfortran. This is fine, because it is the newly built library > that we want to test.
No. It is the same library since I type "make install" before I type "make -i check". > > They worked last week. > Sure, this is a regression. I installed cloog in /usr/local on F10 and needed to use LD_LIBRARY_PATH on this platform also. On i386-redhat-linux we don't have any trouble. > > Here is my most recent test. Above you ask "Could you try before/after this" > > do you mean compile and run the Testuite on both "r143461" and "r143463"? > Yes. But to save time you can update only fortran or libgfortran and narrow > the testsuite run to the failing tests using the RUNTESTFLAGS variable as > explained here http://gcc.gnu.org/wiki/TestCaseWriting OK, I'll be back on my OpenSolaris platform tomorrow. > Furthermore, as your tests show that the failure is in the libgfortran, there > is only one commit in that area in the window you gave (r143454-r143562): > > ------------------------------------------------------------------------ > r143541 | domob | 2009-01-21 14:34:55 +0100 (mer. 21 janv. 2009) | 29 lines > > I don't know though how this could cause system-dependent failures :-(. > Daniel? No reply. > > Thanks for fixing this, > Thanks for helping to fix this. One piece at a time ... Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
