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

[Matt Fago]

As a reporter of the bug/issue (http://gcc.gnu.org/ml/gcc/2006-11/ 
msg00640.html) I think I should chime in here.


Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
> > 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
>
> I'm sorry.  I freely confess that I have hard a time keeping up  
> with all
> that's going on sometimes.  Thanks for being patient with me!
>
> > 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.
>
> I didn't fully understand this before.  I'm sorry.
>
> This switch gives us an dependency on the internals of a package we do
> not maintain.  That sounds like a bad idea.  Part of the justification
> for this may be people who want to build these libraries in-tree,  
> but I
> think we should just stop trying to support that -- until/unless the
> top-level build machinery begins to support staged installations, and,
> then we still wouldn't need special build-directory logic.
> So, I think that this switch should be removed from mainline and 4.2.
> It's just not that hard to type "make install".  Even though the issue
> at hand is 4.1, not mainline, I do think the mainline question is
> relevant, because the existence of the switch means that we might well
> see the same kind of breakage in 4.2, and every future GCC release.
>
> Given that new libmpfr is causing problems for GCC 4.1 users, I agree
> with you that your patch is appropriate there.  Removing the option  
> from
> 4.1.2 would be a needless incompatibility with 4.1.1.  However, I  
> think
> that we should force ourselves to reach consensus on future releases
> before applying to 4.1, so that we don't get to this same situation  
> with
> 4.2.


I do agree that trying to track MPFG/GMP build structures is not a  
good long-term idea.  The 'build-directory' flags could certainly  
IMHO be removed in 4.2 and trunk, however not without changing or  
adding something else, perhaps as below.

As background, the current GCC configure script set to use the  
installed versions of GMP/MPFR is also IMHO very fragile and does not  
support installations on x86_64 Linux or other multilib OS's unless  
the library is installed in PATH/lib, with the headers in PATH/ 
include. Unfortunately, the current configure also only verifies the  
_headers_ are proper versions, and is satisfied with finding _any_  
version of the libraries.  Thus, on x86_64 RHEL4 with GMP/MPFG libs  
in /usr/local/lib64 I was able to successfully pass configure, with  
the compile of GFortran failing 90 minutes later (using I assume the  
older GMP/MPFR installed in /usr/lib).  I suppose I could have  
installed 32-bit versions of the libraries in the GCC preferred  
locations, but frankly I was getting somewhat frustrated.  The 'build  
location' flags did allow me to successfully install GCC 4.1.1 with  
GFortran, once I copied libmpfr.a to the root build directory (hence  
the current patch).

In my humble opinion, ideally, configure with --with-gmp and --with- 
mpfr should search in PATH/lib, PATH/lib32 (64-bit Ubuntu Linux?),  
and PATH/lib64 (64-bit Redhat and SuSE?) for the libraries, as well  
as perform more robust link or other tests on the libraries to assure  
that the versions found by configure are truly acceptable to GCC. A  
runtime test would perhaps be ideal, but I'm not sure exactly how GMP/ 
MPFR are used by GCC and thus if this would work with cross-compilers.

I personally am somewhat worried that the above might be too much of  
a kludge (does some odd OS/distro install libraries in some other  
location etc). Thus, I think a more 'fail-proof' method might be, in  
addition to the more robust link or other library tests, to add the  
add additional flags:

--with-gmp-lib, --with-gmp-include
--with-mpfr-lib, --with-mpfr-include

as Kaveh has graciously already submitted in: http://gcc.gnu.org/ml/ 
gcc-patches/2006-11/msg01310.html. This would allow someone to  
install GCC, no matter how oddly their libraries are installed.   
Perhaps this would be in addition to the current --with-gmp and -- 
with-mpfr flags (the latter are probably more useful to the majority  
of users).  Note that configure would need to correctly report issues  
with finding proper versions of GMP/MPFR to begin with so one  
realizes they need to use the above explicit flags.


Thanks,
Matt