>From: "Kaveh R. GHAZI" <[EMAIL PROTECTED]> >> Matt Fago wrote: >> One issue here is that '--with-mpfr=path' assumes that 'libmpfr.a' is >> in 'path/lib' (not true for how I installed it), while '--with-mpfr- >> dir=path' assumes that 'libmpfr.a' is in 'path', rather than >> 'path/.libs' (can this work for anyone?). Note that '--with-gmp- >> dir=path' does look in 'path/.libs'. > >This problem appears in the 4.0 series all the way through current >mainline. I do believe it should be fixed and it is simple to do so. I'll >take care of it. > >> My comments: >> >> 1) It would have been very useful to have explicit configure options >> such as --with-gmp-lib=path and --with-gmp-include=path (etc) that >> explicitly locate the *.a and *.h directories, rather than (or in >> addition to) the existing "install directory" and "build directory" >> options. > >Yes, the configure included in mpfr itself has this for searching for GMP >which it relies on. I'll add something for this in GCC also.
Thank you. >> 2) Ideally IMHO the top-level configure (or at least the libgfortran >> configure) would test the execution of some or all of the required >> functions in GMP/MPFR. I vaguely recall that this is possible with >> autoconf, and should be more robust. Would it add too much complexity >> to the top-level configure? > >I tend to be reluctant about run tests because they don't work with a >cross-compiler. Would you please tell me specifically what problem >checking at runtime would prevent that the existing compile test doesn't >detect? Yes, a cross-compiler could not do runtime tests. I was trying to think of a more robust configuration-time test. This is difficult as I do not quite understand why configure was successful in finding the libraries with the correct versions, but yet the compilation itself failed. Would a link test against all of the required GMP/MPFR functions (via AC_CHECK_LIB etc) offer anything? Thanks, - Matt
