* [Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem
2012-06-28 14:12 [Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem windward at gmx dot com
@ 2012-06-28 14:31 ` redi at gcc dot gnu.org
2012-07-17 10:10 ` windward at gmx dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2012-06-28 14:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53798
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-06-28 14:30:58 UTC ---
Another, simpler, workaround is to build the support libs by putting the
sources in the gcc source tree.
--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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem
2012-06-28 14:12 [Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem windward at gmx dot com
2012-06-28 14:31 ` [Bug bootstrap/53798] " redi at gcc dot gnu.org
@ 2012-07-17 10:10 ` windward at gmx dot com
2012-07-17 10:11 ` windward at gmx dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: windward at gmx dot com @ 2012-07-17 10:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53798
--- Comment #2 from Martin <windward at gmx dot com> 2012-07-17 10:10:01 UTC ---
Created attachment 27809
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27809
Diffs of a crude workaround
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem
2012-06-28 14:12 [Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem windward at gmx dot com
2012-06-28 14:31 ` [Bug bootstrap/53798] " redi at gcc dot gnu.org
2012-07-17 10:10 ` windward at gmx dot com
@ 2012-07-17 10:11 ` windward at gmx dot com
2012-07-17 10:46 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: windward at gmx dot com @ 2012-07-17 10:11 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem
2012-06-28 14:12 [Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem windward at gmx dot com
` (2 preceding siblings ...)
2012-07-17 10:11 ` windward at gmx dot com
@ 2012-07-17 10:46 ` redi at gcc dot gnu.org
2012-07-17 12:16 ` windward at gmx dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2012-07-17 10:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53798
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-07-17 10:46:27 UTC ---
What's your complete configure command?
Multilib bootstrap on x86_64-linux with --enable-languages=c,c++,java works
fine for me, and for others e.g.
http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg01170.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem
2012-06-28 14:12 [Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem windward at gmx dot com
` (3 preceding siblings ...)
2012-07-17 10:46 ` redi at gcc dot gnu.org
@ 2012-07-17 12:16 ` windward at gmx dot com
2012-07-17 12:18 ` windward at gmx dot com
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: windward at gmx dot com @ 2012-07-17 12:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53798
--- Comment #5 from Martin <windward at gmx dot com> 2012-07-17 12:15:38 UTC ---
IMHO nothing special with the configure call.
SRCDIR=/opt/SP/build/gcc/gcc-4.7.1
Build dir=/opt/SP/build/gcc/gcc-4.7.1-build
INSTPATH=/opt/SP/gcc/gcc-4.7.1
A set of tools including current binutils have been built & installed in
$INSTPATH beforehand, especially libgmp, libmpfr and libmpc. 64 bit libs in
${INSTPATH}/lib64, 32 bit in ${INSTPATH}/lib.
${SRCDIR}/configure --prefix=${INSTPATH} \
--with-gmp=${INSTPATH} --with-mpfr=${INSTPATH} --with-mpc=${INSTPATH} \
--with-gmp-lib=${INSTPATH}/lib64 --with-libelf=${INSTPATH} \
--with-gnu-as --with-as=/opt/SP/gcc/bin/as \
--with-gnu-ld --with-ld=/opt/SP/gcc/bin/ld
The bootstrapping worked perfectly before (4.4-4.6) with the same script, I
just didn't have to build 32 bit MPC, MPFR and GMP libs (and obviously did not
use the corresponding parameters).
The crude workaround in my last attachment works fine as long as LDFLAGS and
LD_LIBRARY_PATH include both ${INSTPATH}/lib64 and ${INSTPATH}/lib. If the
configure script adds _any_ "-Lpath" to $gmplibs / GMPLIBS, libtool will mess
up the linker call by adding the library with full path and filename. If this
wasn't the case, the configure parameters as given above should work.
Any idea why this happens, and only with libjava?
BR Martin
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem
2012-06-28 14:12 [Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem windward at gmx dot com
` (4 preceding siblings ...)
2012-07-17 12:16 ` windward at gmx dot com
@ 2012-07-17 12:18 ` windward at gmx dot com
2012-07-17 12:35 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: windward at gmx dot com @ 2012-07-17 12:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53798
--- Comment #6 from Martin <windward at gmx dot com> 2012-07-17 12:18:11 UTC ---
> --with-gnu-as --with-as=/opt/SP/gcc/bin/as \
> --with-gnu-ld --with-ld=/opt/SP/gcc/bin/ld
Wrong path when replacing the env vars, should read
--with-gnu-as --with-as=/opt/SP/gcc/gcc-4.7.1/bin/as \
--with-gnu-ld --with-ld=/opt/SP/gcc/gcc-4.7.1/bin/ld
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem
2012-06-28 14:12 [Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem windward at gmx dot com
` (5 preceding siblings ...)
2012-07-17 12:18 ` windward at gmx dot com
@ 2012-07-17 12:35 ` redi at gcc dot gnu.org
2012-07-17 13:41 ` windward at gmx dot com
2013-02-26 14:22 ` windward at gmx dot com
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2012-07-17 12:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53798
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-07-17 12:35:39 UTC ---
(In reply to comment #5)
> ${SRCDIR}/configure --prefix=${INSTPATH} \
> --with-gmp=${INSTPATH} --with-mpfr=${INSTPATH} --with-mpc=${INSTPATH} \
> --with-gmp-lib=${INSTPATH}/lib64 --with-libelf=${INSTPATH} \
> --with-gnu-as --with-as=/opt/SP/gcc/bin/as \
> --with-gnu-ld --with-ld=/opt/SP/gcc/bin/ld
And what about when you put gmp, mpfr and mpc in the GCC source tree? That's
what worked fine for me. The same configure command without the
--with-gmp/--with-mpfr/--with-mpc options?
> Any idea why this happens, and only with libjava?
The GCC binaries use GMP, MPFR and MPC internally and the GCC binaries are only
built for a single arch, even if they are capable of producing multilib output.
I don't know but I guess libjava now uses them too, and so multilib libjava
needs multilib support libs.
(In reply to comment #6)
> --with-gnu-as --with-as=/opt/SP/gcc/gcc-4.7.1/bin/as \
> --with-gnu-ld --with-ld=/opt/SP/gcc/gcc-4.7.1/bin/ld
That's redundant, if configure finds an assembler and linker in the
installation directory it will use them.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem
2012-06-28 14:12 [Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem windward at gmx dot com
` (6 preceding siblings ...)
2012-07-17 12:35 ` redi at gcc dot gnu.org
@ 2012-07-17 13:41 ` windward at gmx dot com
2013-02-26 14:22 ` windward at gmx dot com
8 siblings, 0 replies; 10+ messages in thread
From: windward at gmx dot com @ 2012-07-17 13:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53798
--- Comment #8 from Martin <windward at gmx dot com> 2012-07-17 13:41:35 UTC ---
(In reply to comment #7)
> And what about when you put gmp, mpfr and mpc in the GCC source tree? That's
> what worked fine for me. The same configure command without the
> --with-gmp/--with-mpfr/--with-mpc options?
Yep, tried that, failed with undefined references (see comment #3). To be
perfectly honest I did not investigate further since the workaround lets the
build run fine with the pre-compiled libs.
> The GCC binaries use GMP, MPFR and MPC internally and the GCC binaries are
> only built for a single arch, even if they are capable of producing multilib
> output. I don't know but I guess libjava now uses them too, and so multilib
> libjava needs multilib support libs.
Seems so, I never had to provide 32 bit GMP, MPFR and MPC before.
But I rather had libtool in mind. I have never seen it providing a complete
path- and filename when calling the linker. I suppose fixing that will solve
the whole thing - at least with GNU ld, which will pick the right lib if 32 and
64 bit lib paths are given with -L.
> (In reply to comment #6)
> > --with-gnu-as --with-as=/opt/SP/gcc/gcc-4.7.1/bin/as \
> > --with-gnu-ld --with-ld=/opt/SP/gcc/gcc-4.7.1/bin/ld
> That's redundant, if configure finds an assembler and linker in the
> installation directory it will use them.
Errrm... well, yeah. I have _one_ rather large script to build GCC for Solaris
SPARC & x86 and Linux x86. In fact these parameters are env vars, and on
Solaris the linker settings would point to /usr/ccs/bin/ld (without-gnu-ld),
even though the GNU ld is present in the installation dir. Besides that there
are other versions in the PATH, so I prefer not to rely on smart configure
scripts. But thanks for pointing out.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem
2012-06-28 14:12 [Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem windward at gmx dot com
` (7 preceding siblings ...)
2012-07-17 13:41 ` windward at gmx dot com
@ 2013-02-26 14:22 ` windward at gmx dot com
8 siblings, 0 replies; 10+ messages in thread
From: windward at gmx dot com @ 2013-02-26 14:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53798
Martin <windward at gmx dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|4.7.1 |4.7.2
Known to fail| |4.7.2
--- Comment #9 from Martin <windward at gmx dot com> 2013-02-26 14:22:00 UTC ---
Ping?
Bug still exists in 4.7.2, workaround stays the same.
^ permalink raw reply [flat|nested] 10+ messages in thread