> You can use "make check-target-libgfortran", which is what I thought you
> were using to test.
There's no testsuite for libgfortran (the command you mentionned does
not test anything). The only way I'm aware of to run the gfortran
testsuite is "make check-fortran" inside $builddir/gcc. I think I
François-Xavier Coudert wrote:
- with this patch, the libgfortran is built, but the gfortran
testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH
for the testsuite?
It should
Well, it doesn't. The problem is that the gfortran testsuite is not
run with the topl
François-Xavier Coudert <[EMAIL PROTECTED]> writes:
> (after all, make check-gcc and make check-g++
> can be run from the toplevel makefile)
The toplevel makefile only knows about check-gcc, which translates to "cd
gcc; make check" (modulo variable passing). If you want to run only the
g++ tests
>> - with this patch, the libgfortran is built, but the gfortran
>> testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH
>> for the testsuite?
>
> It should
Well, it doesn't. The problem is that the gfortran testsuite is not
run with the toplevel Makefile, but by going into t
- I should add a GMPLBISDIR variable in the configure.in to store the
paths to the libraries as a colon-separated list of absolute paths
- the GMPLIBSDIR should be added to the HOST_LIB_PATH
Yes.
- then, i don't really know how this should come into HOST_LIB_PATH;
perhaps by way of HOST
I've been working on PR libfortran/21547: f951 is linked with libgmp,
but when this library is shared and located in a non-standard path,
building with ./configure --with-gmp=/foo/bar fails because the correct
$(RPATH_ENVVAR) is not set when building the libgfortran. The
conclusions I draw afte
