Bug 44455 - GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
Summary: GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.5.0
: P3 major
Target Milestone: 4.5.2
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 45905 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-06-07 20:42 UTC by Denis Excoffier
Modified: 2011-01-03 15:33 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.6.0
Known to fail:
Last reconfirmed: 2010-06-14 17:51:22


Attachments
Trivial patch (365 bytes, patch)
2010-07-07 07:44 UTC, Marc Glisse
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Excoffier 2010-06-07 20:42:35 UTC
I have compiled sucessfully GCC 4.5.0 under various systems (solaris, cygwin, darwin), using gmp-5.0.1, mpfr-2.4.2 and mpc-0.8.2 installed in the source tree before compilation.

I've tried recently a new MPFR Release Candidate 2 (from http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.tar.bz2) as a replacement for mpfr-2.4.2.tar.bz2.

But It failed within stage 1 of mpfr, at least under darwin and solaris, with the following message:

"header files gmp-impl.h and longlong.h not found"

It seems:
- that GCC compiles mpfr by passing the --with-gmp-build option to its configure,
- that the new mpfr-3.0.0 now detects that the directory given under --with-gmp-build does not contain the necessary files and aborts in this case
- that the same detection was performed under mpfr-2.4.2, albeit with no abort
- the two missing header files are present in the source directory, but not in the build directory (the one given to --with-gmp-build)

I then tried to patch the mpfr/configure in order to skip this test (and the following one "checking for valid GMP_NUMB_BITS"), and it seems to work: GCC is built, and i can use this GCC like before. However i cannot say whether the MPFR part is fully functioning or not.

See also http://websympa.loria.fr/wwsympa/arc/mpfr/2010-06/msg00003.html (the french part of this message is summarized above). According to MPFR people, the bug would reside in GCC.

Hope this helps (the future).

NB. I categorized this problem as more severe as "Normal", since it is likely to affect many targets, and also affect all users that would want to upgrade (blindly) to the last MPFR (within the GCC source directory).
Comment 1 Denis Excoffier 2010-06-11 08:05:30 UTC
The same applies to mpfr-3.0.0 (now official). The MPFR people have however added the following note in ./INSTALL:

> As gmp-impl.h and longlong.h are only in the GMP source directory,
> you first need to copy these files to the build directory if it is
> different (there may be other workarounds, such as setting $CPPFLAGS
> to search the GMP source directory).

This may be a better workaround than the one i proposed first.
Comment 2 nightstrike 2010-06-14 17:35:19 UTC
I can confirm this as a valid bug, but I don't have the bugzilla permissions to do so.  Can someone update this to New?
Comment 3 Nathan Froyd 2010-06-14 17:51:22 UTC
Switched to NEW for NightStrike.
Comment 4 Marc Glisse 2010-07-07 07:44:45 UTC
Created attachment 21121 [details]
Trivial patch

There doesn't seem to be much point using --with-gmp-build (it is mostly useful to improve performance a bit, but gcc explicitly tells GMP to be slow), so let's just use the same options as MPC. It works with mpfr 2.3.1 and 3.0.0. Any particular trap I am missing?
Comment 5 Paolo Bonzini 2010-07-08 16:24:15 UTC
The patch is okay, but it should be tested with bootstrap, `make install' and a smoke test after install with:

- in-tree GMP, in-tree MPFR 2.3
- in-tree GMP, in-tree MPFR 3.0
- out-of-tree GMP, in-tree MPFR 2.3
- out-of-tree GMP, in-tree MPFR 3.0

Comment 6 Andre Heider 2010-07-11 11:17:56 UTC
4.4.4 is affected as well
Comment 7 Marc Glisse 2010-07-12 20:34:21 UTC
(In reply to comment #5)
> The patch is okay, but it should be tested with bootstrap, `make install' and a
> smoke test after install with:
> 
> - in-tree GMP, in-tree MPFR 2.3
> - in-tree GMP, in-tree MPFR 3.0
> - out-of-tree GMP, in-tree MPFR 2.3
> - out-of-tree GMP, in-tree MPFR 3.0

Is it enough to test with --enable-languages=c? What is a smoke test, gcc -v? Does it matter if the system has gmp and mpfr installed, even when doing the in-tree tests (I hope not, because I won't remove them)?
Comment 8 Paolo Bonzini 2010-07-13 09:32:51 UTC
Yes, C-only bootstrap is enough.

Regarding the removal of an installed GMP, in theory yes, it would be preferable.  In practice removing it would force you to use an old bootstrap GCC that does not use MPC/MPFR/GMP, and there is an easy way to check that the right library is used for the build, so it is not necessary.  Since in-tree GMP/MPFR are statically linked, just do "ldd *gcc/cc1" in the build directory, and check that it doesn't include any relevant GMP/MPFR/MPC shared library.

For smoke testing, just compile a simple "int main() {}" file.
Comment 9 Marc Glisse 2010-07-13 14:26:00 UTC
Ok, the 4 tests worked fine. I tested with gcc-4.5.0 because the snapshots complained about the number of arguments to ggc_alloc_cleared_lang_type (without any patch). I used --without-ppl (otherwise you get gmp through it). MPC was in-tree for all tests for the same reason.

ldd on cc1 never showed mpfr, and only showed libgmp.so.3 when it was out of tree. strings on cc1 also confirmed that the right one was used (the system versions of gmp and mpfr are different from the one I tested in-tree).

The versions of mpfr I tested are the latest (3.0.0) and the oldest on which configure only warns and doesn't fail (2.3.1).
Comment 10 Paolo Bonzini 2010-07-13 14:43:23 UTC
Great!  Do you have commit rights?  Patch is ok for all 4.5 and 4.6.
Comment 11 Marc Glisse 2010-07-13 15:01:16 UTC
Sorry, no commit rights. I wrote the patch because it was a one-liner, but I still don't even have a copyright assignment on file.

Can you handle the rest?
Comment 12 Paolo Bonzini 2010-07-13 15:31:04 UTC
Subject: Re:  GCC fails to build if MPFR 3.0.0 (Release
 Candidate) is used

On 07/13/2010 05:01 PM, marc dot glisse at normalesup dot org wrote:
> ------- Comment #11 from marc dot glisse at normalesup dot org  2010-07-13 15:01 -------
> Sorry, no commit rights. I wrote the patch because it was a one-liner, but I
> still don't even have a copyright assignment on file.
>
> Can you handle the rest?

Yep, but I'm on holiday so no hurry. :)

Paolo
Comment 13 Richard Biener 2010-07-23 19:35:40 UTC
Subject: Bug 44455

Author: rguenth
Date: Fri Jul 23 19:35:24 2010
New Revision: 162482

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162482
Log:
2010-07-23  Marc Glisse <marc.glisse@normalesup.org>

	PR bootstrap/44455
	* configure.ac (extra_mpfr_configure_flags): Copy from
	extra_mpc_gmp_configure_flags.
	* configure: Re-generated.

Modified:
    trunk/ChangeLog
    trunk/configure
    trunk/configure.ac

Comment 14 Richard Biener 2010-07-23 19:35:44 UTC
Committed to trunk.
Comment 15 Richard Biener 2010-10-06 10:26:21 UTC
*** Bug 45905 has been marked as a duplicate of this bug. ***
Comment 16 Richard Biener 2010-10-06 10:29:58 UTC
Author: rguenth
Date: Wed Oct  6 10:29:55 2010
New Revision: 165020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165020
Log:
2010-10-06  Richard Guenther  <rguenther@suse.de>

	Backport from mainline
	2010-07-23  Marc Glisse <marc.glisse@normalesup.org>

	PR bootstrap/44455
	* configure.ac (extra_mpfr_configure_flags): Copy from
	extra_mpc_gmp_configure_flags.
	* configure: Re-generated.

Modified:
    branches/gcc-4_5-branch/ChangeLog
    branches/gcc-4_5-branch/configure
    branches/gcc-4_5-branch/configure.ac
Comment 17 Richard Biener 2010-10-06 10:30:18 UTC
Fixed for 4.5.2.
Comment 18 Andreas Beckmann 2010-11-03 09:08:14 UTC
Is there a chance to get this trivial fix backported to 4.4 and 4.3, too?
Comment 19 Vincent Lefèvre 2010-12-12 23:02:58 UTC
FYI, the problem has been handled in the MPFR trunk r7291 for MPFR 3.1.0. MPFR's configure script now retrieves the location of the GMP source from GMP's Makefile and adds the necessary -I... flags to CPPFLAGS.

Note also that the behavior will be different from the one with MPFR 2.x. A side effect is that library versioning is not supported in this case (by that, I mean that a GMP upgrade without recompiling MPFR against the new GMP version may break things) because providing --with-gmp-build makes the MPFR build use GMP's internals, which may change without notice.
Comment 20 Denis Excoffier 2011-01-03 15:33:08 UTC
I confirm that it is fixed in 4.5.2.