[PATCH]: fix the --with-mpfr-dir=PATH configure flag

[Kaveh R. GHAZI]

On Sun, 19 Nov 2006, Mark Mitchell wrote:

> Kaveh R. GHAZI wrote:
>
> > I would respectfully disagree.  Older versions of these libs used to work
> > out of the box with GCC, so the fact that the latest release of mpfr fails
> > in this situation is a true regression.
>
> I'm not sure it matters -- but I'm curious: is this because the GMP/MPFR
> people changed their installation logic, or, do you mean that the latest
> versions as packaged by various GNU/Linux distributors are not set up in
> the way that the 4.1 configure scripts expect?
> Mark Mitchell

For this discussion, it's actually neither.  The installation logic
remains the same across mpfr releases.  The second problem you mentioned
(that the GNU/linux distributors diddle with the locations) also occurs
but I solved it with a separate patch also cc:ed to you here:
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01310.html

The problem problem for this patch is not the installation logic, it's the
mpfr >build directory< structure.  We care about that because the flag I'm
fixing is GCC's --with-mpfr-dir=PATH which allows one to specify a path to
an mpfr source directory where you just compiled mpfr.  Presumably this is
for people who don't want to install mpfr just to build gfortran.

(One can argue the merits of having this flag in the first place, but
since it's been there since 4.0 and I got a bug report about it, I think
we should fix it.)

So currently the GCC configure script looks for mpfr.h and libmpfr.a in
PATH which works for older mpfr releases because they are put in the same
place.  Once they added libtool to mpfr, the archive suddenly gets put
into .libs/libmpfr.a and GCC can't find it.  If you specify
"--with-mpfr-dir=PATH/.libs" then GCC can find the archive but it can't
find mpfr.h.  They no longer live in the same directory.

The mpfr folks didn't do anything wrong in adding libtool, our code was
just too brittle.  GMP already had libtool when we set this up, and GCC
already has the same exact logic to find libgmp.a in several places for
our analogous --with-gmp-dir=PATH flag that I'm proposing for finding
libmpfr.a.

I hope this clarifies things. :-)

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu