[Rd] using openbabel plugins in R

Dirk Eddelbuettel edd at debian.org
Wed Mar 27 18:28:03 CET 2013


On 27 March 2013 at 10:02, Kevin Horan wrote:
| After some more testing I have found that it actually does work if I 
| compile without the plugin library but load it with dyn.load. I'm not 
| sure why this wasn't working before. It only works though if the plugin 
| library is loaded before libobtest2.so (the open babel main lib basically).
|      So, to clarify, the following works now:
| 
| g++ -shared -o libobtest2.so obtest2.o -fpic -lopenbabel -lR
| 
| R>dyn.load("/usr/lib/openbabel/2.2.3/mdlformat.so")
| R>dyn.load("libobtest2.so")
| R>.Call("test")
|    format: 0x7fe114c96d20  #this is the correct result
|    NULL
| 
| 
|      But now I have a chicken and egg problem. The plugin libraries are 
| not stored in a standard directory, but open babel provides a function 
| to list their paths. So I need to load the open babel library to fetch 
| the plugin paths, then I can load the plugins, but, oops, too late, the 
| open babel library is already loaded so loading the plugins now doesn't 

Can use something like pkg-config to query the path?  Eg R offers this
(beyond its own "R CMD config ..." interface:

    edd at max:~$ pkg-config --libs-only-L libR
    -L/usr/lib/R/lib  
    edd at max:~$ 

| work. I tried using dyn.unload("libobtest2.so") but it didn't work. It 
| seems like I'd have to compile a small executable program that uses 
| openbabel to fetch the plugin paths, then run it as an external program 
| from within R, then load the plugins, then load the open babel lib.

Yup. And you could do the test / probing (if that is the last resort) at the
configure test.

|      Does it make any sense that the order in which these are loaded 
| affects things? Is there a way to load the plugin lib later and still 
| have  it work? If the order does have to be maintained, any better ideas 
| how to accomplish this? Thanks.
|      Also, here is the dlopen command that openbabel uses:
|          dlopen(lib_name.c_str(), RTLD_LAZY | RTLD_GLOBAL)

That rings a bell. We once had what I think was that very same issue with
Rmpi as the OpenMPI libraries have there symbols split over several shared
libraries.  But that was many many years ago and I have forgotten what we did
then ...

Dirk

 
| Kevin
| 
| 
| On 03/26/2013 06:54 AM, Dirk Eddelbuettel wrote:
| > On 25 March 2013 at 12:50, Kevin Horan wrote:
| > | I posted this in openbabel-devel but didn't get much help, so hopefully
| > | someone here can help. I don't think its too openbabel specific.
| > |
| > | I would like to make use of open babel from within the R language.
| > | Initially I just need to do some format conversions, but may expand the
| > | usage to other parts of OpenBabel as well. I am familiar with embedding
| > | C/C++ code in R, but I'm having some trouble with the plugin mechanism
| > | of OpenBabel in this case. The  problem is that the formats are not
| > | available when I run the OpenBabel code from within R. So, for example,
| > | if I search for the SDF format like so:
| > |       OBFormat *format = conv.FindFormat("SDF");
| >
| > [...]
| >
| > |      The way it works normally in OpenBabel is that each plugin is its
| > | own shared library and then they get loaded at run time with the dlopen
| > | function (on linux at least). I have verified that this code is still
| > | being executed when called from within R, but it doesn't work for some
| > | reason.
| >
| > I would try to start from the smallest possible working examples.  R itself
| > uses dlopen (see eg $RHOME/modules/ for the files it loads), and so does
| > OpenBabel. Maybe some wires get crossed. You may well have to dig down with
| > the debugger and see what assumptions / environment variables / ... are valid
| > or invalid between the working and non-working case.
| >
| > Dirk
| >
| 
| ______________________________________________
| R-devel at r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com



More information about the R-devel mailing list