On Mon, 29 Jun 2009, Dr. David Kirkby wrote:
--with-libiconv-prefix=/usr/lib/iconv
What's that for? Either you use GNU libiconv or you use libc,
/usr/lib/iconv is just some private libc data.
I find the C compiler works ok. But the C++ compiler can't find its own
library files.
Not the C++ compiler, executables created by said compiler.
kirkby@t2:[~] $ gcc hello_world.c
kirkby@t2:[~] $ ./a.out
hello world
kirkby@t2:[~] $ g++ test.cpp
kirkby@t2:[~] $ ./a.out
ld.so.1: a.out: fatal: libstdc++.so.6: open failed: No such file or directory
Killed
I'm using the Sun linker, not the GNU one, so it's possible g++ is sending
stuff to the linker to indicate where the libraries are, but the linker is
ignoring them.
Ideally I'd like to send something to the Sun linker to day "look in
/usr/local/gcc-4.4.0-sun-linker/lib for libraries too"
You can use the specs file to change the flags passed by gcc to the
linker. gcc -dumpspecs shows the default values and truss will show you
where gcc expects to find a specs file overriding these values. You could
add some -R/my/path in there (depending on m64/m32), which I think is what
Sun currently does in Solaris, although it means LD_RUN_PATH will be
ignored (I think Sun's compiler actually parses this variable to simulate
its effect, but that's too much work for gcc). You could instead add -c
my.config to make the program use an alternate ld.config (created with
crle) which hardcodes a different standard search path for libraries.
--
Marc Glisse
