This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: fix the --with-mpfr-dir=PATH configure flag
- From: Matt Fago <fago at earthlink dot net>
- To: mark at codesourcery dot com, "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, DJ Delorie <dj at redhat dot com>, gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Sun, 19 Nov 2006 21:43:08 -0700
- Subject: Re: [PATCH]: fix the --with-mpfr-dir=PATH configure flag
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
> (that the GNU/linux distributors diddle with the locations) also
> but I solved it with a separate patch also cc:ed to you here:
I'm sorry. I freely confess that I have hard a time keeping up
that's going on sometimes. Thanks for being patient with me!
> The problem problem for this patch is not the installation logic,
> mpfr >build directory< structure. We care about that because the
> 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,
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
4.1.2 would be a needless incompatibility with 4.1.1. However, I
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
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:
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.