[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LD_RUN_PATH not adding paths when building with shared libs
From: |
Olaf Weber |
Subject: |
Re: LD_RUN_PATH not adding paths when building with shared libs |
Date: |
Tue, 02 Sep 2003 12:41:06 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) |
Bill Moseley writes:
> On Thu, Aug 28, 2003 at 05:36:50PM -0500, Tim Mooney wrote:
>> Are you assuming LD_RUN_PATH is something that's honored on IRIX because
>> you've seen it honored on other platforms (e.g. Solaris?). If you've
>> seen it documented somewhere that it should work on IRIX, can you provide
>> information on where I should look?
> Tim,
> You are right.
> I just got a reply back and they built a hello world program and used
> LD_RUN_PATH and strings(1) didn't show the path.
As noted by others, on IRIX you'd use 'elfdump -L' to find whether the
DT_RPATH was set in the ELF dynamic section. (Linux: 'readelf -d')
> The original problem was the built binary was not finding libgcc. The
> first solution was to use LD_RUN_PATH and --disable-shared which worked.
> On linux --disable-shared allowed the use of LD_RUN_PATH (because of
> lack of --rpath at link time). So I assume that's what was happening.
> But, on IRIX with --disable-shared libgcc does not show up in ldd
> output.
This probably means that libgcc.a is being linked instead of
libgcc.so. This is almost always what you want anyway. If want
shared libraries otherwise, try using the '-static-libgcc' option with
gcc. I'd suspect that --disable-shared ends up switching off linking
with shared objects, with the effect on libgcc.so "collateral damage".
--
Olaf Weber
(This space left blank for technical reasons.)
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: LD_RUN_PATH not adding paths when building with shared libs,
Olaf Weber <=