This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [RFC PATCH]: enable building GMP/MPFR in local tree
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Mike Stump <mrs at apple dot com>
- Cc: "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org, fortran at gcc dot gnu dot org, paul at codesourcery dot com, kargl at gcc dot gnu dot org, vincent+gcc at vinc17 dot org
- Date: Mon, 9 Oct 2006 17:47:59 +0000 (UTC)
- Subject: Re: [RFC PATCH]: enable building GMP/MPFR in local tree
- References: <Pine.GSO.4.58.0610081527170.16402@caipclassic.rutgers.edu> <D37792DB-3A71-4C90-B7C5-A247878B11A4@apple.com>
On Mon, 9 Oct 2006, Mike Stump wrote:
> On Oct 8, 2006, at 1:42 PM, Kaveh R. GHAZI wrote:
> > It turned out to be much easier than I thought to decipher the top level
> > machinery and get GMP/MPFR building inside the GCC tree. :-)
>
> Some thoughts, if this configures and builds most (all?) of the time, then we
> are changing the portability profile of gcc to be min(gcc,mpfr,gmp) which
> could be < gcc. If the user has installed a newer gmp/mpfr on the system, do
> we want to use the build tree version anyway? Can we rm -rf gmp/mpfr from the
> source tree to disable the building of these? I suspect all the GMPLIBS and
> GMPINC stuff in the configure script is dead after this (with this version of
> the patch), though, it is probably better to leave it in there for now. What
Clearly --with-system-gmp --with-system-mpfr (like --with-system-zlib)
would be the natural way to enable using the system copies of these
libraries rather than building GCC's local copies. I expect Linux
distributors would use these options to link with the system shared
libraries. We do want to keep something like the existing --with-gmp
--with-mpfr options as well to say where the system copies are, if they
aren't in the default compiler / linker search paths.
> is the change in build time? Do we want to always build it, or only when some
> languages (fortran?) are configured? And lastly, do we want to do this in
> stage 3?
The patch is clearly something being proposed now for discussion and
potential commit in stage 1 or 2. While a proposal as a GCC 4.3 project
would have been a good idea (in fact, it might still make sense to create
a project page linked from
<http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning>), it's not such a big
project as to require such a proposal.
--
Joseph S. Myers
joseph@codesourcery.com