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@max:~$ pkg-config --libs-only-L libR
-L/usr/lib/R/lib
edd@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@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
