Can I specify where g++looks for libs at runtime?

[Marc Glisse]

On Mon, 29 Jun 2009, Dr. David Kirkby wrote:

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

Not sure what you mean, but I think the answer is: no.

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

If you pass a --with-libiconv option, you will use the gnu one. To not use 
it when it is installed in /usr/local is a bit painful, but you could try 
to symlink the system /usr/include/iconv.h in the gcc source tree so it is 
more likely to be found before the one in /usr/local/include (not sure 
that will be enough though, as configure may not look for it there).

> 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

It may be using the iconv implementation in libc (or not using iconv at 
all).

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

By the way, I believe you forgot --disable-nls in your configure options, 
to try and simplify things.

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

No. You use crle (read the man page) to create a config file with your 
favorite search path. Then you pass the linker (ld) the option -c 
myconfigfile. If you try: gcc -dumpspecs, you see what options gcc passes 
to the linker. For instance on this linux computer:

*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %l %{pie:-pie} %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r}    %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}    %{static:} %{L*} %(mfwrap) %(link_libgcc) %o    %{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)} %(mflib)    %{fprofile-arcs|fprofile-generate|coverage:-lgcov}    %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}    %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}

You could add at the end of it:
%{!static:%{!m64:-R/path/lib}%{m64:-R/path/lib/sparcv9}}

Or:
%{!static:%{!m64:-c /path/myconfig}%{m64:-c /path/myconfig64}}

Or you may want to put that elsewhere (in the *libgcc: line?).

Then you put those modified 2 lines in a file called specs at an 
appropriate place (use "truss -f gcc -E empty.c 2>&1 |grep specs" 
(untested) or something like that to determine where that place is).

I haven't used a config file in years, so I am not completely sure how 
they work anymore. In particular, they may be ignored by shared libraries 
and only used by executables.

> Although I do have root access, I'd like to build a solution which does not 
> require the user to have root access.

I know, I never suggested that.

-- 
Marc Glisse