Marc Glisse wrote:
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.
Is the GNU one part of the compiler suite? I noticed on one machine
there was a version of libiconv in /usr/local/lib but I was keen to use
the system one, rather than a local copy.
I noticed on one machine that c++ was linked against a local copy:
$ ldd c++
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libc.so.1 => /lib/libc.so.1
libgcc_s.so.1 =>
/export/home/drkirkby/install-gcc-4.4.0-Sun-as-ld/lib/libgcc_s.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
But on another machine
kirkby@t2:[/usr/local/gcc-4.4.0-sun-linker/bin] $ ldd c++
libc.so.1 => /lib/libc.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,T5240/lib/libc_psr.so.1
It just so happens that I'm having some problems compiling code on the
latter machine, with no link to libiconv, but not on the machine that
does link to a local copy. (I expect this is a red-herring, but it was a
difference I noticed).
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.
Where would I add the -c ?? to crle?
Although I do have root access, I'd like to build a solution which does
not require the user to have root access.
