[Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem

["windward at gmx dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #3 from Martin <windward at gmx dot com> 2012-07-17 10:10:52 UTC ---
(In reply to comment #1)

Hi Jonathan,

> Another, simpler, workaround is to build the support libs by putting the
> sources in the gcc source tree.
may be feasible, but also one could be forced to use existing libs (with
special optimizatoins maybe?).
Tried your suggestion, did not work either:
libbackend.a(builtins.o): In function `fold_builtin_2(unsigned int, tree_node*,
tree_node*, tree_node*, bool)':
builtins.c:(.text+0xcc62): undefined reference to `mpfr_jn'
builtins.c:(.text+0xcc9e): undefined reference to `mpfr_yn'
builtins.c:(.text+0xcdca): undefined reference to `mpfr_lgamma'
builtins.c:(.text+0xce74): undefined reference to `mpfr_remainder'
libbackend.a(builtins.o): In function `fold_builtin_n(unsigned int, tree_node*,
tree_node**, int, bool)':
builtins.c:(.text+0xea1b): undefined reference to `mpfr_remquo'
libbackend.a(builtins.o): In function `fold_builtin_1(unsigned int, tree_node*,
tree_node*, bool)':
builtins.c:(.text+0x17cbe): undefined reference to `mpfr_y1'
builtins.c:(.text+0x17cf6): undefined reference to `mpfr_y0'
builtins.c:(.text+0x1853e): undefined reference to `mpfr_j1'
builtins.c:(.text+0x18573): undefined reference to `mpfr_j0'
/opt/SP/build/gcc/gcc-4.7.1-build/./mpc/src/.libs/libmpc.a(pow.o): In function
`mpc_pow':
pow.c:(.text+0x753): undefined reference to `mpfr_get_z_2exp'
pow.c:(.text+0x7ab): undefined reference to `mpfr_get_z_2exp'
pow.c:(.text+0x7d9): undefined reference to `mpfr_get_z_2exp'
/opt/SP/build/gcc/gcc-4.7.1-build/./mpc/src/.libs/libmpc.a(sin_cos.o): In
function `mpc_sin_cos':
sin_cos.c:(.text+0x1e1): undefined reference to `mpfr_sinh_cosh'
/opt/SP/build/gcc/gcc-4.7.1-build/./mpc/src/.libs/libmpc.a(sqrt.o): In function
`mpc_sqrt':
sqrt.c:(.text+0x27a): undefined reference to `mpfr_min_prec'
sqrt.c:(.text+0x593): undefined reference to `mpfr_min_prec'
collect2: error: ld returned 1 exit status
gmake[3]: *** [jc1] Error 1
gmake[3]: *** Waiting for unfinished jobs....


> --with-gmp behaves as designed and as documented. The installation docs for it
> clearly say:
> The --with-gmp=gmpinstalldir option is shorthand for
> --with-gmp-lib=gmpinstalldir/lib and --with-gmp-include=gmpinstalldir/include.
> [...] If these shorthand assumptions are not correct, you can use the explicit
> include and lib options directly.
Yep. But you cannot use these straightforward to provide the locations of the
required 32 and 64 bit versions for the multilib build. I would expect to give
the _base_ path, and the platform dependent multilib subdirs (lib64 on Linux,
lib/64 on Solaris etc) to be added in the corresponding phase automatically,
and not just plain "/lib".

Additionally I have to correct myself: the build fails even with my workaround.
It seems libtool behaves strange and adds the full path to the libgmp.so:
libtool: link: /opt/SP/build/gcc/gcc-4.7.1-build/./gcc/xgcc
-B/opt/SP/build/gcc/gcc-4.7.1-build/./gcc/ -B/apps/gcc/gcc-4
.7.1/x86_64-unknown-linux-gnu/bin/
-B/apps/gcc/gcc-4.7.1/x86_64-unknown-linux-gnu/lib/ -isystem
/apps/gcc/gcc-4.7.1/x86_
64-unknown-linux-gnu/include -isystem
/apps/gcc/gcc-4.7.1/x86_64-unknown-linux-gnu/sys-include  -m32 -shared 
.libs/gnu_
java_math_GMP.o ../../../native/jni/classpath/.libs/jcl.o   -Wl,-rpath
-Wl,/apps/gcc/gcc-4.7.1/lib64 -Wl,-rpath -Wl,/apps/gcc/gcc-4.7.1/lib64
-L/apps/gcc/gcc-4.7.1/lib64 /apps/gcc/gcc-4.7.1/lib64/libgmp.so
                            ^^ ----------------------------- ^^
-L/opt/SP/gcc/current/lib64 -L/opt/SP/gcc/current/lib/gcc/platform/current 
-m32 -march=core2 -mfpmath=sse -msse3 -mno-ssse3 -mno-avx -m32 -m32   -Wl,-son
ame -Wl,libjavamath.so -o .libs/libjavamath.so

Never seen anything like that before, it should pass -L/path and -lgmp only.
Why is that?

So finally I had to patch all occurences of '-L$with_gmp*' out of
libjava/classpath/configure and to take care that the LDFLAGS and
LD_LIBRARY_PATH are properly set. :-/
I still consider this to be a bug...