[RFC PATCH]: enable building GMP/MPFR in local tree
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. :-)
The patch below is sufficient to build both GMP and MPFR and use them when
linking cc1. When I add in my previous patch for PR 29335 to evaluate
sin/cos/tan at compile-time, it works.
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00360.html
Note: you need to unpack gmp-4.2.1 and mpfr-2.2.0 into the top level gcc
directory and strip off the version numbers from the directory names.
Note2: I did not need any special CFLAGS mentioned by Vincent here:
http://gcc.gnu.org/ml/gcc/2006-10/msg00139.html
Some remaining bits include:
1. Cleaning up the fortran configure hacks that check for GMP/MPFR and
possibly disable building fortran. We always have these libs so we can
always build fortran.
2. Building GMP/MPFR takes a non-trivial portion of the bootstrap. I can
imagine people won't want to do this every time. So we should allow using
the system GMP/MPFR and/or a copy the user built and installed somewhere
assuming they are the correct version. I feel we should require the same
version we have in the tree to avoid bugs in older libraries. I think
this could be a followup patch. OTOH, requiring a minimum version (for
MPFR at least) may not be sufficient. E.g. there is a cumulative patch on
the MPFR site which patches bugs found so far. I imagine we would want to
include this in our local tree, but installed 2.2.0 copies may not have
it. I haven't studied the MPFR patch to see if we care about any of the
fixes in there or not.
3. Assuming we're merciless in requiring an up-to-date version of
GMP/MPFR in #2, remove hacks in fortran that work around bugs in older
copies of GMP/MPFR. We can also do this separately after everything
settles down. Can fortran folks help with this?
4. Finish the transcendetals patch. I.e. update all the math builtins to
take advantage of MPFR. Remove one-off code to evaluate common arguments.
Remove GCC's sqrt calculating function, etc. Add testcases.
I'm including this preliminary patch to solicit feedback about some of the
choices I made. E.g.:
1. I didn't see any point in shared GMP/MPFR libraries so I passed
--disable-shared to both configures. E.g. the xgcc binary doesn't use any
GMP/MPFR functions, so no need to have these as part of the share libs it
loads. Static libs is the way to go.
2. Are there any other special configure flags we want to pass when
building GMP/MPFR? I notice that MPFR does something special when it has
access to the GMP implementation headers. However the implementation
headers are in $(srcdir) while gmp.h is in $(builddir). So I had to
specify only the latter to find gmp.h when configuring MPFR. What exactly
is the benefit to MPFR for having access to the GMP implementation
headers. I.e. is it faster? Any loss if we don't have them?
3. For similar reasons, in the GCC dir I use -I flags which point to the
GMP builddir for gmp.h, but I pass -I for the MPFR source dir for mpfr.h.
I assume this is correct?
4. MPFR wants to check for gmp.h (generated file) and libgmp.a when
configuring, so I had to make a dependency from configure-mpfr on all-gmp.
I assume that's right?
5. Should we install the GMP/MPFR libs built by GCC? I lean towards no.
6. Should we "make check" these two libs? Should we include the results
in the testsuite reports? I lean towards yes for both, but we don't have
to solve that right away. It could also be a follow-up
Any comments on these or any other issues I haven't thought of?
Thanks,
--Kaveh
PS: Patch below has been tested on Solaris 10 with my transcendentals
patch for PR 29335 via a c-only --disable-bootstrap and three-stage -j30
c-only bootstrap on Solaris 7 to ensure I got the dependencies right at
the top level.
2006-10-08 Kaveh R. Ghazi <[EMAIL PROTECTED]>
* Makefile.def: Add entries for GMP and MPFR.
* configure.in (host_libs): Likewise.
* Makefile.in, configure: Regenerate.
gcc:
* Makefile.in (GMPINC, GMPLIBS): Update for in-tree builds.
(LIBDEPS, LIBS): Add $(GMPLIBS).
diff -rup orig/egcc-SVN20061008/Makefile.def egcc-SVN20061008/Makefile.def
--- orig/egcc-SVN20061008/Makefile.def 2006-07-17 20:02:13.0 -0400
+++ egcc-SVN20061008/Makefile.def 2006-10-08 13:58:09.118075306 -0400
@@ -64,6 +64,7 @@ host_modules= { module= gcc; bootstrap=t
extra_make_flags="$(EXTRA_GCC_FLAGS)"; };
host_modules= { module= gawk; };
host_modules= { module= gettext; };
+host_modules= { module= gmp; bootstrap=true;
extra_configure_flags='--disable-shared'; };
host_modules= { module= gnuserv; };
host_modules= { module= gprof; };
host_modules= { module= gzip; };
@@ -82,6 +83,7 @@ host_modules= { module= libtool; };
host_modules= { module= m4; };
host_modules= { module= make; };
host_modules= { module= mmalloc; no_check=true; };
+host_modules= { module=
Re: [RFC PATCH]: enable building GMP/MPFR in local tree
On Sun, Oct 08, 2006 at 04:42:29PM -0400, Kaveh R. GHAZI wrote: > > 3. Assuming we're merciless in requiring an up-to-date version of > GMP/MPFR in #2, remove hacks in fortran that work around bugs in older > copies of GMP/MPFR. We can also do this separately after everything > settles down. Can fortran folks help with this? Yes, I'll cleanup the Fortran frontend. > 6. Should we "make check" these two libs? Should we include the results > in the testsuite reports? I lean towards yes for both, but we don't have > to solve that right away. It could also be a follow-up I think that this is a "yes". The gmp wbe page is constantly warning about build problems with newer gcc. I can't approve the patch, but I'll test it in the next few days. -- Steve
automatic --disable-multilib
Shouldn't configure in gcc be made to automatically test if -m64 is working on the build machine in question and automatically invoke --disable-multilib if not? Currently on Darwin for example we have to explicitly invoke --disable-multilib when building on G4's or non-EMT64 Macintel machines. It would much better if configure would automatically handle this. Jack
Re: automatic --disable-multilib
>Shouldn't configure in gcc be made to automatically test if -m64 > is working on the build machine in question and automatically invoke > --disable-multilib if not? The capability of the build system compiler is meaningless for multilibs. Whether or not multilibbing will work depends on whether -m64 is working in the newly built compiler. Right? Ben
Re: automatic --disable-multilib
Ben, Currently on Darwin and apparently Solaris as well, we have build failures when gcc trunk is built without resorting to --disable-multilib on hardware that doesn't support 64-bits. See PR21561. Jack ps I am told for example that the builds of gcc trunk fail on the non-EMT64 MacBook Pro in this fashion... checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[1]: *** [configure-target-libstdc++-v3] Error 1 Relevant lines from i386-apple-darwin8.8.1/x86_64/libstdc++-v3/ config.log: configure:2694: checking for C compiler default output file name configure:2697: /Users/sandro/z/./gcc/xgcc -B/Users/sandro/z/./gcc/ - B/usr/local/i386-apple-darwin8.8.1/bin/ -B/usr/loca l/i386-apple-darwin8.8.1/lib/ -isystem /usr/local/i386-apple- darwin8.8.1/include -isystem /usr/local/i386-apple-darwin8. 8.1/sys-include -m64 -O2 -g -O2conftest.c >&5 configure:2700: $? = 0 configure:2746: result: a.out configure:2751: checking whether the C compiler works configure:2757: ./a.out ../../../../gcc-4.2/libstdc++-v3/configure: line 1: ./a.out: Bad CPU type in executable On Mon, Oct 09, 2006 at 09:15:50AM +1000, Ben Elliston wrote: > >Shouldn't configure in gcc be made to automatically test if -m64 > > is working on the build machine in question and automatically invoke > > --disable-multilib if not? > > The capability of the build system compiler is meaningless for > multilibs. Whether or not multilibbing will work depends on whether > -m64 is working in the newly built compiler. Right? > > Ben
Re: automatic --disable-multilib
On Oct 8, 2006, at 4:35 PM, Jack Howarth wrote: Ben, Currently on Darwin and apparently Solaris as well, we have build failures when gcc trunk is built without resorting to --disable-multilib on hardware that doesn't support 64-bits. See PR21561. It'd be possible for non-cross compiles to engineer something up in the configure, but it would only work for occasions when you already had a compiler installed that supported the 64-bit multilib since you'd need to have it around to build it. Or, as Ben said, it's only when you have already built the new compiler that you'll know and might as well pass --disable-multilib and start the build again :) -eric
Re: automatic --disable-multilib
Eric, The problem we have in fink is that the absence of a check for viable -m64 build support in the compiler causes failures on G4s and non-EMT64 hardware when the gcc4 package is built without --disable-multilib. It seems odd that out of all the checks configure does in build that it doesn't at least verify that -m64 works with the existing compiler. Jack ps You realize of course that most fink packages outside of the standard releases aren't available as prebuilt binaries for download so the user has to build it locally from the current packaging scripts. On Sun, Oct 08, 2006 at 04:44:54PM -0700, Eric Christopher wrote: > > On Oct 8, 2006, at 4:35 PM, Jack Howarth wrote: > > >Ben, > >Currently on Darwin and apparently Solaris as well, we have > >build failures when gcc trunk is built without resorting to > >--disable-multilib on hardware that doesn't support 64-bits. > >See PR21561. > > > > It'd be possible for non-cross compiles to engineer something up > in the configure, but it would only work for occasions when you already > had a compiler installed that supported the 64-bit multilib since you'd > need to have it around to build it. Or, as Ben said, it's only when you > have already built the new compiler that you'll know and might as well > pass --disable-multilib and start the build again :) > > -eric
Re: automatic --disable-multilib
Jack Howarth <[EMAIL PROTECTED]> writes: >Shouldn't configure in gcc be made to > automatically test if -m64 is working on > the build machine in question and automatically > invoke --disable-multilib if not? Currently > on Darwin for example we have to explicitly > invoke --disable-multilib when building on > G4's or non-EMT64 Macintel machines. It would > much better if configure would automatically > handle this. I believe trying to disable the multilib is fundamentally the wrong approach. I have posted a patch which I believe is the correct approach to the automake list, where it is awaiting review.
