Problem with dyn.load'ed code

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with dyn.load'ed code

Matt Calder-2
All,
        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 one already defined in R. The result is that the function
in my code is not called. Here is an example

// lnktst.cc
extern "C"
{
  void func(double *out1, double *out2);
  void dnrm2_(double *out);
  void dnrm3_(double *out);
}

void func(double *out1, double *out2)
{
  dnrm2_(out1);
  dnrm3_(out2);
}

void dnrm2_(double *out)
{
  *out = 1234.5;
}

void dnrm3_(double *out)
{
  *out = 6789.0;
}
// End of lnktst.cc

When I compile:

g++ -shared -static -o lnktst.so lnktst.cc

and then in R I call "func"

> dyn.load("lnktst.so")
> .C('func', double(1), double(1))
[[1]]
[1] 0

[[2]]
[1] 6789

So, as you can see, the function "dnrm2_" is not called whereas "dnrm3_"
is, even though both functions are identical in form. Now, I believe
dnrm2_ is a BLAS function, and so it is likely R already has a copy
floating around. However, it surprises me that the "-static" option does
not force the call in my code to "dnrm2_" to be linked to the function
defined in my code.
        I have been writing C code for Splus for quite a while and don't recall
ever running across this issue. However, I am new to R, so I wonder, am
I missing something obvious?  
        I am running this on Ubuntu Linux, the output of uname -a is:

Linux calder-linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

Thanks for any help,

        Matt

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load'ed code

Simon Urbanek
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 one already defined in R.

The result of redefining a symbol is very much system-dependent. For  
example on Mac OS X it has no adverse effects (i.e your symbols are  
always private unless linked against), because it uses a two-level  
namespace, but on Linux (and most other unices) it does as the  
namespace of an executable is shared among all modules (dynamic and  
static).


> The result is that the function in my code is not called. Here is an  
> example
>
> // lnktst.cc
> extern "C"
> {
>  void func(double *out1, double *out2);
>  void dnrm2_(double *out);
>  void dnrm3_(double *out);
> }
>
> void func(double *out1, double *out2)
> {
>  dnrm2_(out1);
>  dnrm3_(out2);
> }
>
> void dnrm2_(double *out)
> {
>  *out = 1234.5;
> }
>
> void dnrm3_(double *out)
> {
>  *out = 6789.0;
> }
> // End of lnktst.cc
>
> When I compile:
>
> g++ -shared -static -o lnktst.so lnktst.cc
>
> and then in R I call "func"
>
>> dyn.load("lnktst.so")
>> .C('func', double(1), double(1))
> [[1]]
> [1] 0
>
> [[2]]
> [1] 6789
>
> So, as you can see, the function "dnrm2_" is not called whereas  
> "dnrm3_" is, even though both functions are identical in form. Now,  
> I believe dnrm2_ is a BLAS function, and so it is likely R already  
> has a copy floating around.

Yes, indeed (it's a BLAS level 1 Fortran function, and usually to be  
found in libRblas.so or the external BLAS implementation).


> However, it surprises me that the "-static" option does
> not force the call in my code to "dnrm2_" to be linked to the function
> defined in my code.

You are confusing the purpose of -static: it only ensures that static  
libraries are used at link time where possible, it doesn't affect your  
code in any way. What you really want is to use
static void dnrm2_(double *out);
in your code instead.

In general, it is a bad idea to use external symbols that clash with  
other libraries (in particular widespread ones such as BLAS),  
especially if your function doesn't perform the same operation. It is  
a good idea to declare all functions that you use internally (i.e.  
that should not be visible to R) as static. However, all this is true  
for C programming in general, not just in conjunction with R.

Cheers,
Simon


> I have been writing C code for Splus for quite a while and don't  
> recall
> ever running across this issue. However, I am new to R, so I wonder,  
> am
> I missing something obvious?
> I am running this on Ubuntu Linux, the output of uname -a is:
>
> Linux calder-linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT  
> 2007 i686 GNU/Linux
>
> Thanks for any help,
>
> Matt
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load'ed code

Matt Calder-2
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.
        So, I have a set of Fortran code in which some BLAS functionality is
replicated. I am writing an interface to some of the functions in that
code (not to the BLAS part, that is used internally by ARPACK). I would
like it if that interface did not require alteration of the library
source code or build process (though it is open-source, so if need be I
can change it).
        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
caused it to resolve all references at link time. So something like:

ld -o my_code_and_arpack.o -static my_code.o -larpack

would pull all the references from the two object files (my_code.o and
libarpack.a) and link them as needed, and unresolved references would
cause an error. I guess that impression is wrong, but how does one
accomplish the same thing?
        Thanks for any help,

        Matt
       

On Sun, 2007-12-30 at 20:21 -0500, Simon Urbanek wrote:

> 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 one already defined in R.
>
> The result of redefining a symbol is very much system-dependent. For  
> example on Mac OS X it has no adverse effects (i.e your symbols are  
> always private unless linked against), because it uses a two-level  
> namespace, but on Linux (and most other unices) it does as the  
> namespace of an executable is shared among all modules (dynamic and  
> static).
>
>
> > The result is that the function in my code is not called. Here is an  
> > example
> >
> > // lnktst.cc
> > extern "C"
> > {
> >  void func(double *out1, double *out2);
> >  void dnrm2_(double *out);
> >  void dnrm3_(double *out);
> > }
> >
> > void func(double *out1, double *out2)
> > {
> >  dnrm2_(out1);
> >  dnrm3_(out2);
> > }
> >
> > void dnrm2_(double *out)
> > {
> >  *out = 1234.5;
> > }
> >
> > void dnrm3_(double *out)
> > {
> >  *out = 6789.0;
> > }
> > // End of lnktst.cc
> >
> > When I compile:
> >
> > g++ -shared -static -o lnktst.so lnktst.cc
> >
> > and then in R I call "func"
> >
> >> dyn.load("lnktst.so")
> >> .C('func', double(1), double(1))
> > [[1]]
> > [1] 0
> >
> > [[2]]
> > [1] 6789
> >
> > So, as you can see, the function "dnrm2_" is not called whereas  
> > "dnrm3_" is, even though both functions are identical in form. Now,  
> > I believe dnrm2_ is a BLAS function, and so it is likely R already  
> > has a copy floating around.
>
> Yes, indeed (it's a BLAS level 1 Fortran function, and usually to be  
> found in libRblas.so or the external BLAS implementation).
>
>
> > However, it surprises me that the "-static" option does
> > not force the call in my code to "dnrm2_" to be linked to the function
> > defined in my code.
>
> You are confusing the purpose of -static: it only ensures that static  
> libraries are used at link time where possible, it doesn't affect your  
> code in any way. What you really want is to use
> static void dnrm2_(double *out);
> in your code instead.
>
> In general, it is a bad idea to use external symbols that clash with  
> other libraries (in particular widespread ones such as BLAS),  
> especially if your function doesn't perform the same operation. It is  
> a good idea to declare all functions that you use internally (i.e.  
> that should not be visible to R) as static. However, all this is true  
> for C programming in general, not just in conjunction with R.
>
> Cheers,
> Simon
>
>
> > I have been writing C code for Splus for quite a while and don't  
> > recall
> > ever running across this issue. However, I am new to R, so I wonder,  
> > am
> > I missing something obvious?
> > I am running this on Ubuntu Linux, the output of uname -a is:
> >
> > Linux calder-linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT  
> > 2007 i686 GNU/Linux
> >
> > Thanks for any help,
> >
> > Matt
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
http://www.piskorski.com/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load'ed code

Matt Calder-2
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 R_func_*. This is going
to be my new SOP.
        Thanks again Andrew, and also Simon. I greatly appreciate you taking
your time to solve this problem for me.

        Matt

       
On Mon, 2007-12-31 at 15:30 -0500, Andrew Piskorski wrote:

> 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
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load'ed code

Simon Urbanek
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 portable. It is probably ok  
for your private compilation, but it won't work in general. In any  
case, I'd strongly recommend enabling this hack only if you know that  
the target system supports it for the sake of portability. However, if  
you are concerned about the latter, you should probably have a look at  
libtool and --export-symbols - it allows you to control the visibility  
on most systems that support it.
Note that there are systems that don't support it at all.

Cheers,
Simon


> where ver.map is the file:
>
> {
>     global: R_func_*;
>     local:*;
> };
>
> and any function I want exported to R is named R_func_*. This is going
> to be my new SOP.
> Thanks again Andrew, and also Simon. I greatly appreciate you taking
> your time to solve this problem for me.
>
> Matt
>
>
> On Mon, 2007-12-31 at 15:30 -0500, Andrew Piskorski wrote:
>> 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
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel