[Top][All Lists]
[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