Re: Including GMP/MPFR in GCC repository?

[Richard Earnshaw <rearnsha at arm dot com>]

On Tue, 2006-10-10 at 04:22, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
> > Has there been any thought to including GMP/MPFR in the GCC repository
> > like we do for zlib and intl?
> 
> I do not think we should be including more such packages in the GCC 
> repository.  It's complicated from an FSF perspective and it bloats our 
> software.  GCC is a complicated piece of software, and to build it you 
> need a lot of stuff installed on your system.  I think we should just 
> accept that. :-)
> 
> I think that making our build system more complicated, and adding more 
> packages, with the goal of making life simpler for people building from 
> source is deceptive.  It doesn't seem particularly harder to build and 
> install a few libraries and then install GCC.  But, making our build 
> system more complex gives us more ways to make mistakes.  It also tempts 
> us to add lots of configuration options for in-tree and "system" 
> versions of the libraries, for building but not installing libraries, etc.
> 
> I do think we should do is provide a known-good version (whether via a 
> tag in some version control system, or via a tarball) of these libraries 
> so that people can easily get versions that work.
> 
> (For avoidance of doubt, the above statements are just my opinions as a 
> GCC developer; they're in no way "official".)

I think there's a very important distinction that needs to be drawn
between a tool that needs to be installed to *build* gcc and a tool that
needs to be installed in order to *run* gcc.  GMP/MPFR is needed for the
latter; and to date we have never relied on such an external component
that isn't part of the base installation of a system (such as libc).

What makes this worse is that a specific version of this package is
needed, so this can make upgrading/developing the compiler difficult
since other packages may be built and expect older versions.  There was
major resistance to hard-coding the search path for the shared library
into the object file.

R.