Re: [PATCH]: fix the --with-mpfr-dir=PATH configure flag

["Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>]

On Mon, 20 Nov 2006, Matt Fago wrote:

> >From: "Kaveh R. GHAZI" <ghazi@caip.rutgers.edu>
> >I believe the configure test already has a link time check with an mpfr
> >function, mpfr_init.  In order to fix it, I need you to help me understand
> >why this link test (incorrectly?) passes.  Please try the 4.1 vs mainline
> >configure, because they are slightly different.
>
> Why yes it does do a link test for MPFR -- don't know how I missed that.
> Thanks. Is mpfr_init() only found in the desired versions of MPFR?
> Otherwise I'm not sure that this test is as complete as one would like.
>
> I retested 4.1.1 configure and recovered the same behavior.  I also tested
> mainline via the gcc-20061118 snapshot with
>
>        ../srcdir/configure --with=languages=fortran


Shouldn't that be --enable-languages=fortran  ?

And what's your --with-gmp=/--with-mpfr= flags?


> This build also results in a successful configure, but a failed build during
> gfortran bootstrap. However, the error message is now much more helpful:
>

> gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
> -Wstrict-prototypes-Wmissing-prototypes -Wold-style-definition
> -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
> driver-i386.o ../libcpp/libcpp.a
> ../libiberty/libiberty.a../libdecnumber/libdecnumber.a -lmpfr -lgmp
> /tmp/new-software/gcc-4.3-20061118-build/./gcc/xgcc -B/tmp/new-software/gcc-4.3-20061118-build/./gcc/ -B/usr/local/x86_64-unknown-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[3]: *** [specs] Error 127

This is wierd.  In your gcc command, there's no -L flag to tell gcc where
to find either libgmp or libmpfr.  So either the configure process thinks
they are in a standard system library area, or something else went wrong.
You'll need to check the output from your top level configure run and the
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 find the
shared library.  This usually means you successfully linked xgcc/cc1 with
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.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu