[Rd] Problem with dyn.load'ed code

[Andrew Piskorski]

On Sun, Dec 30, 2007 at 10:43:50PM -0500, Matt Calder wrote:
> Simon,
> 	Thanks for the reply. Indeed, declaring the function static fixes the
> example. Unfortunately, the real problem that gave rise to the example
> arises in a large Fortran library that is not under my control (ARPACK).
> The author is providing BLAS and LAPACK functionality intentionally.
> That may or may not be good practice, but it is a given in this case.

Ok, so R is calling its one "dnrm2_" function, let's call this "A",
while ARPACK defines a second, different "dnrm2_", which we'll call
"B".  You want to call function A from your own C code, while R keeps
calling function A as before without any change or interference.  And
of course, A and B are two C-coded functions with different behaviors
but the exact same name.  You can make that work, it just requires
some tricks.

> 	I still feel like the linker ought to be able to solve this problem for
> me. My impression was that the static keyword passed to the linker

It can, you just need to tell it exactly what you want.  I assume you
are building your own custom C code into a shared library, which you
then load into R.

Thus, one solution is to statically link the ARPACK library into your
own shared library, and then carefully tell the linker which symbols
to export and which to keep private inside your shared library.  As
long as the symbol ARPACK's "B" dnrm2_ function is kept private inside
your own shared library (not exported), R will never see it and will
happily keep using dnrm2_ "A" as before.

That's how I've solved this sort of name collision problem in the
past.  In your "src/Makevars", you may want something like to this:

  PKG_LIBS = -Wl,--version-script=vis.map -Wl,-Bstatic -L/usr/local/lib/ARPACK -lARPACK -Wl,-Bdynamic

You may also need a PG_PKG_LIBS with the same stuff, but I don't
remember why.  The '--version-script=' and related matters were also
disccussed here back in February:

  https://stat.ethz.ch/pipermail/r-devel/2007-February/044531.html

-- 
Andrew Piskorski <atp at piskorski.com>
http://www.piskorski.com/