This is the mail archive of the gcc-help@gcc.gnu.org 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: Can I specify where g++looks for libs at runtime?


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


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