I believe this is a bug in GCC 4.5.1 build system related to the introduction of MPC. I'm compiling GCC 4.5.1 and all its dependencies in my home directory and installing all (make install) at $HOME/OpenFOAM/ROOT At some GCC build stage it fails with this messages: --------------------------------------- checking for powerpc64-unknown-linux-gnu-strip... strip checking whether ln -s works... yes checking for powerpc64-unknown-linux-gnu-gcc... /bgpusr3/avibrz/OpenFOAM/gcc-build/./gcc/xgcc -B/bgpusr3/avibrz/OpenFOAM/gcc-build/./gcc/ -B/bgpusr3/avibrz/OpenFOAM/ROOT/powerpc64-unknown-linux-gnu/bin/ -B/bgpusr3/avibrz/OpenFOAM/ROOT/powerpc64-unknown-linux-gnu/lib/ -isystem /bgpusr3/avibrz/OpenFOAM/ROOT/powerpc64-unknown-linux-gnu/include -isystem /bgpusr3/avibrz/OpenFOAM/ROOT/powerpc64-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: in `/bgpusr3/avibrz/OpenFOAM/gcc-build/powerpc64-unknown-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[2]: Leaving directory `/bgpusr3/avibrz/OpenFOAM/gcc-build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/bgpusr3/avibrz/OpenFOAM/gcc-build' make: *** [all] Error 2 --------------------------------------- Side note: /bgpusr3/avibrz == $HOME Having a look at /bgpusr3/avibrz/OpenFOAM/gcc-build/powerpc64-unknown-linux-gnu/libgcc/config.log I find this: --------------------------------------- configure:3211: checking for suffix of object files configure:3233: /bgpusr3/avibrz/OpenFOAM/gcc-build/./gcc/xgcc -B/bgpusr3/avibrz/OpenFOAM/gcc-build/./gcc/ -B/bgpusr3/avibrz/OpenFOAM/ROOT/powerpc64-unknown-linux-gnu/bin/ -B/bgpusr3/avibrz/OpenFOAM/ROOT/powerpc64-unknown-linux-gnu/lib/ -isystem /bgpusr3/avibrz/OpenFOAM/ROOT/powerpc64-unknown-linux-gnu/include -isystem /bgpusr3/avibrz/OpenFOAM/ROOT/powerpc64-unknown-linux-gnu/sys-include -c -g -O2 conftest.c >&5 /bgpusr3/avibrz/OpenFOAM/gcc-build/./gcc/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory configure:3237: $? = 1 --------------------------------------- But libmpc.so.2 is there. I even took care of creating artificial symbolic links to satisfy this bizarre 'powerpc64-unknown-linux-gnu' under ROOT. This is how I'm configuring GCC as I took care of passing correct directories for MPC installation: --------------------------------------- gcc-build$ ../gcc-4.5.1/configure --prefix=$HOME/OpenFOAM/ROOT --with-stage1-ldflags="-L$HOME/OpenFOAM/ROOT/lib" --with-gmp="$HOME/OpenFOAM/ROOT" --with-mpfr="$HOME/OpenFOAM/ROOT" --with-ppl="$HOME/OpenFOAM/ROOT" --with-mpc="$HOME/OpenFOAM/ROOT" --enable-languages=c++,fortran --------------------------------------- Any tip ?
set LD_LIBRARY_PATH so the dynamic loader can find libmpc.so.2
I was able to make it pass that stage explicitly setting the library path like this: gcc-build$ LD_LIBRARY_PATH=$HOME/OpenFOAM/lib make I found this was not related to MPC since I moved to 4.4.4 (pre-MPC version of GCC) and I got same problem with MPFR (another GCC dependency). Since I'm already using --with-mpfr=DIRNAME, I was expecting that the library path was being set automatically. So I still consider this a weak point on the build system that could be automatically managed.
GCC doesn't set runpaths in executables, this is intentional: http://gcc.gnu.org/faq.html#rpath If you don't want those support libs installed for their own sake and are only installing them for GCC to use, then a simpler way to build it is to put the gmp, mpfr and mpc sources under gcc-4.5.1 (renamed from gmp-x.y.z to just gmp, and similarly for mpfr and mpc) and then just configure gcc without any --with-{gmp,mpfr,mpc} options. That way gcc will build with those sources and doesn't need to find the shared libs. Or you can build the libs with --disable-shared so that gcc will have to link statically to libgmp.a, which also avoids needing to find the shared libs. Or you can just make sure the shared lib can be found, using LD_LIBRARY_PATH or LD_RUN_PATH or ldconfig. (In reply to comment #0) > But libmpc.so.2 is there. I even took care of creating artificial symbolic > links to satisfy this bizarre 'powerpc64-unknown-linux-gnu' under ROOT. Don't do that.
this should be documented, either under the --with-gmp configuration docs or in the faq
Jonathan, your comment #3 was very helpful. I have a very bizarre situation dealing with cross compilers and entire platforms that must run in my home directory. Maybe the best and easier thing for my case is to statically link GCC to its dependencies.
Now I have a better understanding of GCC build system.
I'm going to add something to the docs, so I'll keep this PR open until I do that, so reopening ...
... and assigning to myself again
fixed by http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02135.html the online docs should update overnight