http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45806
terry at chem dot gu.se changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |WORKSFORME
--- Comment #5 from terry at chem dot gu.se 2010-09-27 13:13:43 UTC ---
OK, this is a bit strange.
The offending error is:
/home/tjf/InstallTrees/gcc-4.5.1-build/./gcc/cc1: error while loading shared
libraries: libmpc.so.2: cannot open shared object file: No such file or
directory
Now libmpc.so.2 -> libmpc.so.2.0.0 both exist in /usr/local/lib, along with all
the other libraries that are regularly linked to. Back up in the top-level
config.log we have
configure:5665: gcc -o conftest -g -O2 conftest.c -lmpc -lmpfr -lgmp >&5
which worked happily.
/usr/local/lib is listed in /etc/ld.so.conf.d/libc.conf and usually works.
LD_LIBRARY_PATH is unset.
Explicitly setting LD_LIBRARY_PATH to /usr/local/lib has gcc compiling past
this point as we speak.
I've never before had library path issues on this machine. On a very similar
x86_64 machine (that has LD_LIBRARY_PATH explicitly set by default) 4.5.1
compiled without issue.
I'll close this now, but will nonetheless welcome any comments anyone wants to
make that might shed light on why my configuration appears to have gone
selectively bung.
