This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: fix the --with-mpfr-dir=PATH configure flag
Hope you don't mind -- I'm removing the CCs to Mark et al.
On Nov 21, 2006, at 10:35 AM, Kaveh R. GHAZI wrote:
On Mon, 20 Nov 2006, Matt Fago wrote:
I retested 4.1.1 configure and recovered the same behavior. I
mainline via the gcc-20061118 snapshot with
Shouldn't that be --enable-languages=fortran ?
Oops. Yes, it was of course ...
And what's your --with-gmp=/--with-mpfr= flags?
I was able to recreate the issue (successful configure, failed build)
without using either. Unfortunately I was required to do an OS update
during the middle of this, so ...
This build also results in a successful configure, but a failed
gfortran bootstrap. However, the error message is now much more
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o cpp gcc.o
opts-common.o gcc-options.o cppspec.o intl.o prefix.o version.o
../libiberty/libiberty.a../libdecnumber/libdecnumber.a -lmpfr -lgmp
linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -
isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/
local/x86_64-unknown-linux-gnu/sys-include -dumpspecs > tmp-specs
/tmp/new-software/gcc-4.3-20061118-build/./gcc/xgcc: error while
loading shared libraries: libmpfr.so.1: cannot open shared object
file: No such file or directory
make: *** [specs] Error 127
This is wierd. In your gcc command, there's no -L flag to tell gcc
to find either libgmp or libmpfr. So either the configure process
they are in a standard system library area, or something else went
You'll need to check the output from your top level configure run
contents of top level config.log to see where things went wrong.
Also, the command line says "gcc" but the error message says
/path/to/xgcc. The error message also seems to say that it can't
shared library. This usually means you successfully linked xgcc/
a library *not* in the standard system areas and then forgot to set
LD_LIBRARY_PATH so the dynamic loader could find it later on.
There may be two build commands listed above? Yes, I agree it is odd.
I would think that configure would automagically deal with the
library paths though. I'll investigate more ...