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).
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.
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?
Switched to NEW for NightStrike.
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?
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
4.4.4 is affected as well
(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)?
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.
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).
Great! Do you have commit rights? Patch is ok for all 4.5 and 4.6.
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?
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
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
Committed to trunk.
*** Bug 45905 has been marked as a duplicate of this bug. ***
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
Fixed for 4.5.2.
Is there a chance to get this trivial fix backported to 4.4 and 4.3, too?
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.
I confirm that it is fixed in 4.5.2.