This project is read-only.


Oct 10, 2013 at 2:38 PM
Edited Oct 10, 2013 at 4:25 PM
I'm having trouble getting R.NET to load on OSX (10.8.3).

  • Install latest Mono 3.2.3
  • Download the ZIP for Unix and unzip
  • export PATH=$PATH:/Library/Frameworks/R.Framework/Libraries/
  • Place the following in a test.fsx, compile it using "fsharpc test.fsx" and run using "mono test.exe"
  • Tracing reveals that the code fails at a "dlopen" call when being passed /Library/Frameworks/R.Framework/Libraries/libR.dylib
  • This file exists and I can't work out why it isn't loaded. Recompiling with "--target:x64" doesn't help

    ENTER: (wrapper managed-to-native) RDotNet.NativeLibrary.UnmanagedDll:dlopen(string,int([STRING:0x80bc60:/Library/Frameworks/R.Framework/Libraries/libR.dylib], 1, )
    LEAVE: (wrapper managed-to-native) RDotNet.NativeLibrary.UnmanagedDll:dlopen (string,int)result=0

    [ Update: I've confirmed that this is a 32bit v. 64bit problem. Mono on Mac OSX is 32-bit-only by default. R is 64-bit by default. If you build a custom Mono from source using then the problem goes away ]

#r "RDotNet.dll"
#r "RDotNet.NativeLibrary.dll"

open RDotNet

let main argv =  
    let engine = REngine.CreateInstance("test")
Oct 11, 2013 at 5:08 AM
Thanks for reporting this experience. Many discussions in this list touch on 32/64 bits mismatches, and your post helps as a reference for further questions.

I do not have access to OSX (yet) but similar issues are encountered on Windows with "LoadLibrary failed" types of messages lacking specificity.

I'll see whether specific messages and checks can be made in R.NET at load time. I've an idea for a helper class to locate the R native library from Windows registry and other means on Unix-like systems systems, to alleviate some tedium in setting up. I think the creator of the library already looked at this for setting up unit test.
Oct 20, 2013 at 8:46 AM
I've updated the documentation page for R.NET 1.5.5, including clarifications on how to set up environmental variables. Let me know if you spot issues notably WRT MacOSX.

More importantly to limit the kind of issue you reported with 32/64 bit mismatch, the upcoming version of R.NET will have more detailed error/exception messages, and by default the environment setup will try to work "automagically" for most users but with a customizable fallback for special software setups.
Oct 22, 2013 at 1:12 AM
Hi jperraud,

Related to this and the issues I put on the issue tracker yesterday, I just found out that on Mac OSX, the Environment.OSVersion.Platform call used in the documentation example to find the library to load, returns "Unix" and not "MacOSX" as expected, which causes headaches.

I have some work arounds for this, but noticed you mentioned you have already changed a lot on the upcoming version, will this be released soon? Would hate to reinvent the wheel, but if problems still exist am happy to help.


PS Have not forgotten about r2Clr. There was some discussion on the mono mailing list awhile ago about how Xamarin studio and the default mac install should be 64 bit soon now that the iphone is. I figured this would solve the issue and so was simply waiting for that to happen, am surprised it hasn't yet.

PPS, does anyone know the answer to this question, I think it may explain some oddities I have been seeing with the environmental variables settings.

Assume mono starts and loads the shared library "dlopen" with one set of environmental variables. Now, have C# code change the environmental variables, and make a call to load the "" library. Mono simply states that this library is already loaded and hands the original pointer to the library it loaded off, as mono and C# run in the same process. Does the dlopen library now see the new environmental variables? Or is it set to the old version still?
Oct 22, 2013 at 1:19 AM
I guess unix instead of macosx is the known return value:
Oct 22, 2013 at 7:41 AM
Hi Nigel,

Kosei did notice this behavior, and put code in place to overcome it:
               var kernelName = ExecCommand("uname", "-s");
               return kernelName == "Darwin" ? PlatformID.MacOSX : platform;
It was not used in some places however (possibly my oversight BTW), at least not on the branch I develop on, so your post was a very useful reminder. Talking about branch, this is the branch 'jperraud'. Have a look if you can, and let me know if you notice issues. Your workaround may be better, and could replace the call to uname. I guess it is called a few times at the Rengine setup time only, so it not too onerous.

As it happen, I just spent an afternoon with a friend who has a Mac laptop building rClr; we got through the build process, and have a sketch of documentation. We did bump into the 64bit R and 32 bits Mono issue too, overcome by compiling Mono from source, with a few bumps along the way. In the end more unit tests passed than I hoped for, so a really pleasing outcome. I won't expand further on it in this post, but I noticed R.NET failed to load, something possibly related to this Platform enum issue. In any case running the unit tests on MacOS would be welcome, as I cannot. Note in passing that on Windows I can run from Visual Studio all unit tests "class by class"; but runing the lot in one go has issues, probably to do with repeated R engine init/destroy.

Not sure when my changes can be incorporated in a release; I'll contact Kosei, see what his workload is. I am aiming to work on unit tests, fixes and alleviating selected usage issues reported by users.

I am not on top of the native P/Invoke layer, but if you see a way to avoid compilation flags, this is a worthwile pursuit. Note taken.
Oct 22, 2013 at 5:23 PM
Ah, I see this code now. The documentation page on this site points to:
  var platform = Environment.OSVersion.Platform;
and if that is updated to the native utility, that should work just fine. My solution was to check for some mac specific paths, but this seems more robust (though perhaps caching the result after the first call would be good to?

I recently compiled 64 bit mono on my MAC, it actually failed at some point during the process, but I think it "made" all the important bits, so haven't run in to too much trouble, will try it out again soon.

I'll try to look more at R.NET and RCLR in the coming days.