This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]