autoconf
[Top][All Lists]
Advanced

[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: Bill Moseley
Subject: Re: LD_RUN_PATH not adding paths when building with shared libs
Date: Thu, 28 Aug 2003 16:47:04 -0700
User-agent: Mutt/1.5.4i

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?

I don't have access to the IRIX machine -- that was something that came 
from the person I was trouble shooting for -- I've asked him to try a 
simple test with LD_RUN_PATH and report back.

> >Now try with --disable-shared:
> >
> >address@hidden:~/swish-e$ ./configure --disable-shared 
> >--prefix=$HOME/test_again >/dev/null
> >address@hidden:~/swish-e$ LD_RUN_PATH=/home/moseley/swish-e/filters make 
> >install >/dev/null
> >address@hidden:~/swish-e$ strings /home/moseley/test_again/bin/swish-e | 
> >grep moseley
> >/home/moseley/swish-e/filters
> >/home/moseley/test_again/lib/swish-e
> >
> >Now LD_RUN_PATH is getting in the binary.  Is this expected?
> 
> You don't know that it's LD_RUN_PATH that's causing
> /home/moseley/swish-e/filters to appear in the binaries, though, do you?
> Couldn't be that it's getting in there because of some other reason?

No, it's not in there for any other reason because it's just some random
directory I picked and LD_RUN_PATH was the only change I made.  You are
right that I'm not 100% sure that it's in there because LD_RUN_PATH
(LD_RUN_PATH in the environment might be causing something else to
happen along the way, true).

> >If it is expected how should users that have other library requirements
> >(like libgcc on IRIX) add in a path at build time?
> 
> If the library doesn't specify it itself, the only way I'm aware of is
> via the `-rpath' option of ld.  The linker will include the RPATH from
> libraries in the binary it generates, though, so you wouldn't need -rpath
> when linking your binary if libgcc_s.so.N internally specified an RPATH
> for where to find it and its dependencies.

I guess I'm not following.  That's probably my fault because I don't 
know this stuff well, and only on a few platforms.

Basically, what happened was someone tried to build the package and it 
said at link time:

  rld: Fatal Error: Cannot Successfully map soname'libgcc_s.so.1' under any of 
the filenames

But they had that on their system.  I suggested that they try 
LD_RUN_PATH to point to the location of libgcc, which would be a normal 
way to extend the search path.

That didn't work but they reported back that using LD_LIBRARY_PATH 
worked.  Libtool was adding -rpath during the build so I assume that was 
overriding the LD_RUN_PATH.  Assuming is the word there.

In my testing (on Linux) I found also that LD_RUN_PATH was not used when 
I built the package, but if I used --disable-shared I was able to get 
paths from LD_RUN_PATH into the binary.

That also worked on the IRIX system.


The issue is how do I offer help to people trying to build
our package on various platforms (and often for people with little 
experience building from source).  Perhaps I depended on LD_RUN_PATH too
much to solve problems with libraries in non-standard places in the 
past.

So what seems to have happened is that by using --disable-shared that 
removed the use of -rpath when linking which let LD_RUN_PATH work.

Under normal ./configure && make the link line includes:

   -Wl,--rpath -Wl,/usr/local/lib

but with --disable-shared --rpath is not used.

See, it's not entirely obvious (to me, I should say) that LD_RUN_PATH 
and --disable-shared work against each other.

So the question, after all that, is maybe LD_RUN_PATH is the wrong 
suggestion, and instead I should say:

   ./configure && make LDFLAGS='-R /path/to/non-standard/library'




-- 
Bill Moseley
address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]