Matt,
On Jan 1, 2008, at 12:08 PM, Matt Calder wrote:
> Andrew,
> Thanks! The version script worked like a charm. Specifically I now
> build using:
>
> g++ -shared -Wl,--version-script=ver.map to_dyn_load.cc -o
> to_dyn_load.so -larpack
>
just a word of warning - this is in no way portab
Andrew,
Thanks! The version script worked like a charm. Specifically I now
build using:
g++ -shared -Wl,--version-script=ver.map to_dyn_load.cc -o to_dyn_load.so
-larpack
where ver.map is the file:
{
global: R_func_*;
local:*;
};
and any function I want exported to R is named
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).
> T
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.
T
Matt,
On Dec 30, 2007, at 5:25 PM, Matt Calder wrote:
> I am still having trouble dyn.load'ing some code into R. I have
> isolated the problem, I wonder if someone could explain what I am
> seeing.
> I think the problem is that a symbol defined in my compiled code
> clashes with
You are missing some extern "C" declarations? R needs C linkage style.
Basically a lot of:
extern "C" {
}
around your c++ code.
Matt Calder wrote:
> Hi,
> I am having trouble with some code that I am dyn.loading. I am
> writing an interface to ARPACK. I compile my interface (dssimp.cc), an
