This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

As a reporter of the bug/issue ( 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:

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

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: 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]