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

[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]

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

             Bug #: 53798
           Summary: [4.7] Bootstrap fails on Linux x86_64 with pre-built
                    libmpc/mpfr/gmp due to multilib path problem
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: windward@gmx.com


GCC 4.7.1 fails to bootstrap on Linux x86_64 due to a multilib problem if
pre-built libraries for MPC, MPFR and GMP are used and their installation
directory is set using --with-[mpc|mpfr|gmp] (see output at the end).

Obviously these libraries reside in different paths for 32 bit and 64 bit.
The main configure script (line 5108 and following) evaluates the
--with-[mpc|mpfr|gmp]=PATH parameters and extends $gmplibs with "-LPATH/lib".
The resulting GMPLIBS is used in ./Makefile.in and ./gcc/Makefile.in, and
causes the bootstrapping to fail in either 32 or 64 bit multilib stage
(depending on the parameters). 
Besides the redundancy if all libraries reside in the same path, $gmplibs can
only be correct for either 32 or 64 bit.

Workaround:

Assumption: 32 bit libraries reside in PATH/lib, the 64 bit versions in
PATH/lib64

Use --with-[mpc|mpfr|gmp]=PATH and add --with-gmp-lib=PATH/lib64.

The configure script will generate GMPLIBS with (at least) -LPATH/lib64 and
-LPATH/lib. GNU ld will ignore the incompatible version while searching for
lib[mpc|mpfr|gmp].


/opt/SP/build/gcc/gcc-4.7.1-build/./prev-gcc/g++
-B/opt/SP/build/gcc/gcc-4.7.1-build/./prev-gcc/
-B/opt/SP/gcc/gcc-4.7.1/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/opt/SP/build/gcc/gcc-4.7.1/libstdc++-v3/libsupc++
-L/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc  -o jc1 \
        java/class.o java/decl.o java/expr.o java/constants.o java/lang.o
java/typeck.o java/except.o java/verify-glue.o java/verify-impl.o
java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o
java/mangle_name.o java/builtins.o java/resource.o java/jcf-depend.o
java/jcf-path.o java/boehm.o java/java-gimplify.o main.o  libbackend.a
libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a -L../zlib -lz  libcommon.a ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  attribs.o  
-L/opt/SP/gcc/gcc-4.7.1/lib -L/opt/SP/gcc/gcc-4.7.1/lib
-L/opt/SP/gcc/gcc-4.7.1/lib -lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz

/opt/SP/gcc/gcc-4.7.1/bin/ld: __gmpfr_emin: TLS definition in
/opt/SP/gcc/gcc-4.7.1/lib64/libmpfr.so.4 section .tdata mismatches non-TLS
definition in /usr/lib/../lib64/libmpfr.a(exceptions.o) section .data
/opt/SP/gcc/gcc-4.7.1/lib64/libmpfr.so.4: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
gmake[3]: *** [jc1] Error 1
gmake[3]: Leaving directory `/opt/SP/build/gcc/gcc-4.7.1-build/gcc'

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

[redi at gcc dot gnu.org]

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.

[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]

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

[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]

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...

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

[redi at gcc dot gnu.org]

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

[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]

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

[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]

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

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

[redi at gcc dot gnu.org]

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.

[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]

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.

[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]

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.