I am trying to help with porting some code that uses the C foreign function
interface from Linux to Mac OS X and have been trying a toy example
on both systems. I have actually been very impressed by how easy it
was to get started with the interface, but I did note some small issues
with the documentation.
The first point is with the release notes, which do say that the C Interface
was not supported on Mac OS X once upon a time, but don?t say that
it is supported now. (Aside: do time profiling and polling work now too?)
The web page about the C Interface says that load_lib will raise
an exception if the dynamic library cannot be found.
My experience on both OSes is that load_lib and load_sym don?t raise any exceptions.
You get the exception when you try to call a C function. The documentation
also says that it will kill your ML session if the file exists but has the wrong format,
but that seems to have been fixed now.
It says that if load_lib is called with a relative path name,
then it will be interpreted with respect to the directory in which the ML
session was started from. I don?t think this can be right. Surely you will get
whatever behaviour dlopen gives you (and typically that will be a search
involving environment variables like LD_LIBRARY_PATH and some
OS-specific standard places like /lib). So, for example, if mylib.so
is in the current directory and I pass ?mylib.so? to load_lib, on Fedora, I get
load_lib <mylib.so> : mylib.so: cannot open shared object file: No such file or directory
If I change ?mylib.so? on the call to load_lib to ?./mylib.so? or run with
LD_LIBRARY_PATH=. or copy mylib.so into /usr/lib64, it works.
On Mac OS X, on the other hand, if have ?mylib.dylib? in my current directory,
load_lib will find it given the relative pathname, because dlopen on Mac OS X
includes the current directory as one of the standard places.
Regards,
Rob.