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.