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

On Sun, 19 Nov 2006, Matt Fago wrote:

> 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 believe the configure test already has a link time check with an mpfr
function, mpfr_init.  In order to fix it, I need you to help me understand
why this link test (incorrectly?) passes.  Please try the 4.1 vs mainline
configure, because they are slightly different.

>  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).

As I've stated, I am against automatically searching extra directories.
I feel we'll be constantly updating the list of automatic locations to
satisfy everyone and never get it complete.  We'll also risk
"automatically" finding the wrong library.  Rather than get it partially
correct we should just add the separate lib/include flags below allowing
users to specify separate locations for header vs library.

> 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).

Correct, I'm not removing the --with-gmp/--with-mpfr shortcut flags.  (No
relation to the *-dir flags.)

Kaveh R. Ghazi

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