Re: Can't find a library that's right there
Hi Ross
I found the thread by accident when browsing a web archive of
debian-devel, I'm no longer subscribed here as the volume is too high
for my available time. Feel free to bug me in private on this too
(given that I'm the R maintainer, that is).
On Sat, Aug 21, 2004 at 10:10:07PM +0200, Goswin von Brederlow wrote:
> 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.
Still, I'd recommend this for a _standalone_ binary.
But you said earlier in the thread that you wanted to distribute this as
part of an R package -- in which case things are different because ...
>
> > 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.
... /usr/bin/R is _exactly_ the kind of wrapper script Goswin talks
about here.
E.g., witness ldd on the .so of my RQuantLib packages:
dd@homebud:~> ldd /usr/lib/R/site-library/RQuantLib/libs/RQuantLib.so
libQuantLib-0.3.7.so => /usr/lib/libQuantLib-0.3.7.so (0x400bb000)
libR.so => not found
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x404b5000)
libm.so.6 => /lib/libm.so.6 (0x4056f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40591000)
libc.so.6 => /lib/libc.so.6 (0x4059a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
edd@homebud:~>
The morale here is that iff
a) you want to build a regular, CRAN-style R package that will get
loaded by R using library() or require(), then the normal manual
'Writing R Extensions' fromin the various r-doc-* packages applies,
and everything just works if you build the package using
R CMD build .... as described --- this will set up the linker
calls for you etc pp
b) you want to embed R into another application, things are a little
different but I am not sure if that is the case here.
> 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.
FWIW I fully agree with the 'no-no' view. There is one ugly-ish fudge
that also works: Given that /usr/bin/R sets LD_LIBRARY_PATH for you,
/usr/lib/R/bin will in fact searched. So for one package which expects
to link R with another private set of .so libs not otherwise know to ldd
(via ld.so.conf or other means), I simply softlinked from their
/usr/lib/$foo/lib$foo.so into /usr/lib/R/bin/lib$foo.so.
> > 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.
I think you'd be well advised to follow a) above. Bug me is something is
unclear; otherwise follow any of those over 350 CRAN packages that
contain C/C++ code to see how they do. It really is taken care of by R
itself thanks to its build mechanism.
Dirk
--
Three out of two people have difficulties with fractions.
Reply to: