Thanks for all the suggestions. I have discovered that the problem is
fixed in openbabel 2.3.x. I had actually been testing with open babel
2.3.2 (as well as 2.2.3), but I was running it from the build directory
since I didn't want to install it on the system as I was only testing
with it. Because of this, 2.3.2 failed in the same way as 2.2.3 (the
version actually installed), but for a different reason (It couldn't
find the modules directory ). Actually installing 2.3.2 fixed the problem.
Kevin
On 03/27/2013 11:20 AM, Simon Urbanek wrote:
On Mar 27, 2013, at 1:02 PM, 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.
Run the egg in a separate R process (i.e. use system() to call another R
process which loads libobtest2.so and calls the API to get the path). Then load
the modules followed by the .so.
Note that all this is inherently fragile and probably not portable (e.g. it
seems to assume flat namespaces). Another way (only slightly less fragile) is
to link libobtest2.so against the modules directly.
The real issue seems in openbabel - there is really no reason why it shouldn't
be loading the modules. I didn't look at it, but it could be that it is simply
trying to detect things in the wrong namespace and thus mis-detecting something
in R as its own. It's obviously a bad design in openbabel as it's polluting the
global namespace, but that's another story... (Linux users won't notice as
Linux doesn't support two-level namespaces AFAIK).
Cheers,
Simon
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 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.
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)
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel