Most popular GMP downloads

Richard Biener rguenther at
Thu Apr 24 08:00:06 UTC 2014

On Wed, 23 Apr 2014, Andreas Enge wrote:

> On Wed, Apr 23, 2014 at 01:13:32PM +0200, Richard Biener wrote:
> > Like the following?  I'll commit it if you think that is ok. 
> I think this would be quite helpful already, unless it will cause a
> diplomatic incident with the people working on my bug report.
> But you may wish to check the actual minimal requirements, I think
> they are higher:
> > -Necessary to build GCC at .  If a GMP source distribution is found in a
> > +Necessary to build GCC at .  It can be donwloaded from @uref{}.
> Typo in "downloaded".


> > - at item MPFR Library version 2.4.2 (or later)
> > + at uref{}.  Older versions than 2.4.0 will not work.
> > - at item MPC Library version 0.8.1 (or later)
> > + at item MPC Library
> > +0.8.0 will not work.  If an MPC source distribution
> I think here it really is 2.4.2 and 0.8.1 and not the .0 release.

I checked the configure script and it accepts the .0 releases
(but complains "buggy but acceptable").  Similar for GMP where
it accepts 4.2.3 but complains until you have at least 4.3.2.

> > Note that we intentionally allow "old" versions to work to don't increase
> > the burden of compiling new GCC versions on old platforms.
> Well, that is okay, people having these old versions installed (who should be
> fewer and fewer, even my stable debian ships gmp-5.0.5) can still use them
> at their own risk. The problem is with newbies being enticed to expressly
> download and install outdated versions.

Yeah, I understand that.  In the past it was also that the in-tree
build variant (that is recommended if you don't have a system
installed version that works) broke with newer versions due to
changes in the build system of gmp/mpfr/mpc.  This is why we
usually recommend to go _exactly_ with the version we tested
(not that we really do that and update the version info), not
the "newest" version - especially for older GCCs.  We apply dances

host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
                no_install= true;
                // none-*-* disables asm optimizations, bootstrap-testing
                // the compiler more thoroughly.
                // gmp's configure will complain if given anything
                // different from host for target.
                target="none-${host_vendor}-${host_os}"; };
host_modules= { module= mpfr; lib_path=.libs; bootstrap=true;
                no_install= true; };
host_modules= { module= mpc; lib_path=.libs; bootstrap=true;
@extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@';
                no_install= true; };

to support the in-tree bootstrap and


because we don't do intermediate installs but need the builds to pickup
dependecies from the build directory of the dependence ... which
at least in the past was quite fragile with especially GMP changing
its build system.  Now consider people mixing and matching random
"ok" versions of gmp/mpfr, say, use gmp 6.0.0 and mpfr 2.4.2 ...

There is also no easy way (working across gmp/mpfr/mpc releases)
to check for the version of an in-tree variant without first
building it (thus we apply no version check there).

This is why we "duplicate" tarballs at - we direct people to
download from there.  We even have a script to automate that,
using _exact_ versions we were supposed to have tested for each
release - contrib/download_prerequesites.  As older versions
of that script should not cease to work we have multiple versions
out there (and to avoid gobbling up too many we are hesitant to
update them regularly).

I'll see to update the versions used for GCC trunk.


Richard Biener <rguenther at>
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer

More information about the gmp-devel mailing list