[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-03 11:15 ---
*** Bug 42584 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||lxndrmxwll at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424

[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

[ghazi at gcc dot gnu dot org]

--- Comment #1 from ghazi at gcc dot gnu dot org  2010-01-02 16:24 ---
I was able to do a C-only bootstrap of mainline with all three libraries
in-tree on x86_64-unknown-linux-gnu.  I used mpc-0.8, mpfr-2.4.2, gmp-4.3.1 and
bootstrapped with gcc-4.3.2.  I cannot reproduce this problem, so we need more
info, e.g.

1.  Is this a recent regression or has it always failed?
2.  What versions of the various libraries did you use?
3.  Does it fail with all versions of the libs or just some?
4.  The targets listed include darwin9 and i686-linux, do they both fail for
the same reason?
5.  Do you have other versions of gmp/mpfr installed somewhere that conflict
with the bootstrap?
6.  Is there more info or investigation you can provide?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424

[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

[developer at sandoe-acoustics dot co dot uk]

--- Comment #2 from developer at sandoe-acoustics dot co dot uk  2010-01-02 
16:41 ---
(In reply to comment #1)
 I was able to do a C-only bootstrap of mainline with all three libraries
 in-tree on x86_64-unknown-linux-gnu.  I used mpc-0.8, mpfr-2.4.2, gmp-4.3.1 
 and
... 
 1.  Is this a recent regression or has it always failed?
since the introduction of mpc - prior to that I had been using in-tree mpc/mpfr
with no issues.
[however the first version of mpc I've used is 0.8.1].
 2.  What versions of the various libraries did you use?
gmp-4-3-1, mpfr-2-4-1 source trees.
mpc-0.8.1 source tree
 3.  Does it fail with all versions of the libs or just some?
I haven't built with mpc prior to 0.8.1 - but these same gmp/mpfr versions
*were* OK prior to the introduction of mpc.
 4.  The targets listed include darwin9 and i686-linux, do they both fail for
 the same reason?
yes - configure fail for mpc.
 5.  Do you have other versions of gmp/mpfr installed somewhere that conflict
 with the bootstrap?
no, I don't install any of these libs on darwin.  
I have installed on i686-linux *since*, but the fault occurred on a fresh
ubuntu 9.10 install.

 6.  Is there more info or investigation you can provide?
make check (mpc part) also fails when the mpc is built in tree - even when the
gm/mpfr libs are supplied using --with-{gmp,mpfr}= ... this perhaps points at
an mpc config change between 0.8 and 0.8.1 - since 0.8 works for you.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424

[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2010-01-02 19:53 
---
OK, I can reproduce the issue.

1. I have a GCC trunk (rev. 155544). In there I put symlinks to gmp-4.3.1,
mpfr-2.4.2 and mpc-0.8.1
2. From an empty build directory, I configure with: ../trunk/configure
--prefix=/Users/fx/devel/gcc/irun --enable-languages=c
3. make fails with:

checking for __gmpz_init in -lgmp... no
configure: error: libgmp not found or uses a different ABI.
make[2]: *** [configure-stage1-mpc] Error 1
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2


The problem is actually not an ABI one, but that the mpc configure fails with:

configure:10805: checking for __gmpz_init in -lgmp
configure:10830: gcc -o conftest -g -fkeep-inline-functions
-I/Users/fx/devel/gcc/ibin-intree/./gmp -I/Users/fx/devel/gcc/trunk/mpfr   
conftest.c -lgmp   5
ld: library not found for -lgmp

The problem is that mpc isn't told where to find the gmp and mpfr libraries. It
is confirmed by the mpc configure command-line (from mpc/config.log):

/Users/fx/devel/gcc/trunk/mpc/configure --cache-file=./config.cache
--prefix=/Users/fx/devel/gcc/irun --enable-languages=c
--program-transform-name=s,y,y, --disable-option-checking
--build=x86_64-apple-darwin10.2.0 --host=x86_64-apple-darwin10.2.0
--target=x86_64-apple-darwin10.2.0 --srcdir=../../trunk/mpc
--disable-intermodule --enable-checking=yes,types --disable-coverage
--enable-languages=c --disable-shared
--with-gmp-include=/Users/fx/devel/gcc/ibin-intree/./gmp
--with-mpfr-include=/Users/fx/devel/gcc/trunk/mpfr


This can be contrasted with mpfr, which is configured with
'--with-gmp-build=/Users/fx/devel/gcc/ibin-intree/./gmp', and thus knows where
to find libgmp. So it seems that the following patch should be applied to
configure.ac:

Index: configure.ac
===
--- configure.ac(revision 155544)
+++ configure.ac(working copy)
@@ -1287,7 +1287,7 @@
 if test x$with_mpfr$with_mpfr_include$with_mpfr_lib = x  test -d
${srcdir}/mpfr; then
   gmplibs='-L$$r/$(HOST_SUBDIR)/mpfr/.libs -L$$r/$(HOST_SUBDIR)/mpfr/_libs
'$gmplibs
   gmpinc='-I$$r/$(HOST_SUBDIR)/mpfr -I$$s/mpfr '$gmpinc
-  extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr'
+  extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr
--with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs'
   # Do not test the mpfr version.  Assume that it is sufficient, since
   # it is in the source tree, and the library has not been built yet
   # but it would be included on the link line in the version check below
@@ -1321,7 +1321,7 @@
   gmplibs='-L$$r/$(HOST_SUBDIR)/gmp/.libs -L$$r/$(HOST_SUBDIR)/gmp/_libs
'$gmplibs
   gmpinc='-I$$r/$(HOST_SUBDIR)/gmp -I$$s/gmp '$gmpinc
   extra_mpfr_configure_flags='--with-gmp-build=$$r/$(HOST_SUBDIR)/gmp'
-  extra_mpc_gmp_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp'
+  extra_mpc_gmp_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp
--with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs'
   # Do not test the gmp version.  Assume that it is sufficient, since
   # it is in the source tree, and the library has not been built yet
   # but it would be included on the link line in the version check below



Except that on some targets, .libs is actually called _libs. I don't know
how to deal with that.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 19:53:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424