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

[Matt Fago]

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  
>> also tested
>> mainline via the gcc-20061118 snapshot with
>>
>>        ../srcdir/configure --with=languages=fortran
>
>
> 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  
>> 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.

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

  - Matt