Re: Can't find a library that's right there
Ross Boylan <ross@biostat.ucsf.edu> writes:
> I've found several solutions, and have a theory of the problem. If
> anyone could comment on the theory, that would be great.
>
> SOLUTIONS
> The best solution seems to be to include
> -Wl,-rpath,/usr/lib/R/bin
> as an option to gcc.
That has all theproblems associated with rpath and is only valid
within a package. If you use an rpath to link in another package
library you get problems on future updates and version skews.
> Setting LD_LIBRARY_PATH also worked, when I remembered to export
> it. (duh)
This can be done by a wraper script and avoids most problems caused by
rapth. Worst case you can change the wraper script to fix bugs.
But both of those realy are only appropriate for within a single
package. If you (R package exporting a library) have libraries that
are ment to be linked to by other they should follow the FSH and be in
a public place (/usr/lib/). Then you (package linking against R libs)
don't have this problem.
> Editing ld.so.conf also worked.
I think that is a big no-no.
> Only the first meets my needs, since I want to redistribute the work
> (as part of an R package), and it needs to work without extra
> environment tweaking.
>
> THEORY
> I'm still puzzled the the -L/usr/lib/R/bin didn't work. My theory is
> that the linker simply sticks in a reference to mspath.so, but does
> not attempt to resolve its dependencies. That only happens at
> run-time, at which point -L (but not -runpath) is lost. Does that
> sound right?
-L only tells the compile time linker where to look. Without rpath it
is assumed the runtime libarry will be in the search path later. With
rpath you hardcode the full path into the binary and no runtime
searching is done.
> RESPONSES TO EARLIER POSTS
>
> I wasn't sure that LD_LIBRARY_PATH affects links. However the link
> command line included -L. Further, in the examples further down in my
> original post I ran the program both with my default LD_LIBRARY_PATH
> (empty) and with /usr/lib/R/bin in it (but only set locally). As the
> examples showed, in neither case was the program able to find libR.so,
> nor could ldd.
>
> By the way, as shown in the original post, mspath.so also had
> -L/usr/lib/R/bin -lR in its link command.
As it should if the lib is there.
MfG
Goswin
Reply to: