Installing matlab ruby on OS X

Installing matlab-ruby on OSX (Snow Leopard).
I have tried this on Snow Leopard. There are also instructions for older (i.e. 32-bit) OSX versions, which I haven’t tried.

1 Use the normal installation of Matlab. The ‘x86_64’ check box must be checked (this is the default). This installs Matlab in a directory named, for instance,
/Applications/MATLAB_R2009b.app

2 Open the Terminal utility (Applications/Utilities).

3 In the new session, type

echo ‘export PATH=~/.gem/ruby/1.8/bin:$PATH’ >> ~/.profile

This will add the necessary path.
Close the Terminal window and open another one (cmd-N)

4 In the new session, type

- if you are using a 64-bit OS (like Snow Leopard) :

export ARCHFLAGS=‘-arch x86_64’

This will force compilations that happen in the next step to generate a gem for 64-bit operation, which is what you need.
(The default option would have you build a fat binary for both 32- and 64-bit operation, which I have not been able to build, and you probably don’t want it anyway).

- otherwise, for 32-bit OS versions, it may be useful to enter

export ARCHFLAGS=‘-arch i386’

for the same reason.

5 Now type this:

gem install matlab-ruby V - —with-matlab-include=/Applications/MATLAB_R2009b.app/extern/include —with-matlab-lib=/Applications/MATLAB_R2009b.app/bin/maci64 —with-englib=eng

(note the two dashes between “-V” and “—with-matlab-include=…”)

where
-V causes Verbose output (this really helps when something doesn’t work)
—with-matlab-include= etc, specifies the directory where engine.h is located
—with-matlab-lib= etc, specifies the directory containing the dynamic library which has the compiled code for the matlab function engOpen(). On the mac this file is called libeng.dylib. On Snow Leopard the default integer size for applications is 64 bit, so you must give the location of the 64bit version of this library (from the matlab root, bin/maci64). For older versions of the MacOS (which are 32-bit based), use bin/maci instead.
—with-englib= etc, specifies the name of the dynamic library which contains engOpen(). The file is called libeng.dylib – however the only part that you must enter is “eng”, as the compiler expects the name to start with “lib” and to finish with ‘.dylib’.

At some point you should see ‘Successfully installed matlab-ruby-2.0.3’, followed by a number of ‘No definition for…’ which are generated by the documentation process, and should only be taken as warnings, not errors.

6 Now things will get really ugly…
The gem generated uses dynamic linking with the matlab libraries ; this works by storing the name and path of the libraries to be linked with, in the executable file.
However, this name and path is obtained by copying a string located inside each .dylib.
In the case of the matlab libraries, the structure of this path is relative : caller and library must be in the same directory.

The way I used fix this issue is not very elegant and could probably be improved : I copied
- from the matlab directory that contains its libraries (/Applications/MATLAB_R2009b.app/bin/maci64 in my system)
- to the directory that contains my gem (directory (~/.gem/ruby/1.8/gems/matlab-ruby-2.0.3/lib)
- the following files:
- all .dylib
- all aliases
- icudt40l.dat, libicudata.dylib.40.0, libicui18n.dylib.40.0, libicuio.dylib.40.0, and libicuuc.dylib.40.0
I copied these using the Finder (there are 300+ files).
If you forget to copy one of these, don’t worry : you’ll get, in the next steps, an error message with the name of the missing file.

If someone comes up with a more elegant approach to this issue, please publish it.

7 Return to a Terminal window and change the current directory to the one containing the gem:

cd ~/.gem/ruby/1.8/gems/matlab-ruby-2.0.3/lib

8 Test the matlab-ruby operation : start an interactive ruby session with

irb -d

This gives you a Ruby environment in which you can experiment.
Notice the ‘-d’ flag; it makes error messages more detailed if the interpreter fails, such as ‘missing libXXXX.dylib’.

9 Type

require ‘matlab’

This should return ‘true’. If it doesn’t, it’s probably because the current directory has not been set (see above).

10 Type

engine = Matlab::Engine.new

This will take a few seconds to execute, and after a few warnings about memory leaks, you should see

#<Matlab::Engine: etc.

At that stage you can consider that everything is working: you have created an instance of the matlab engine, and you can manipulate it with Ruby. For instance

engine.eval ‘1+2’

should return

3.0

Cheers !