Posts Tagged ‘mex’

Installing and running fmmlib from MATLAB on Mac OS X

Tuesday, December 26th, 2017

No better way to finish 2017 than trying to compile some old fortran code. This time it’s the fast multipole method library from nyu, fmmlib.

Here’s how I did it on a MacBook Pro running OS X 10.12 with MATLAB r2018a pre-release.

First install gfortran using homebrew via:

brew install gcc

Now we need to convince to use find and use gfortran.

Download gfortran.xml


Download gfortran.xml

In MATLAB issue:

copyfile('~/Downloads/xcode7_mexopts/gfortran.xml',fullfile( matlabroot, 'bin', 'maci64', 'mexopts' ))

On the command line, install gfortrani8 in the same directory as gfortran. I did this via:

cp ~/Downloads/gfortrani8 /usr/local/Cellar/gcc/7.2.0/bin/gfortrani8

Now, the following should succeed in MATLAB to setup the gfortran compiler:

mex -setup -v FORTRAN

For posterity: If you get “sdk” related issues, you may need to copy all the 10.13 lines in gfortran.xml and create analogous lines for 10.14 etc.

It seems like the '-compatibleArrayDims' flag should be used with fmmlib, but honestly I’m not sure. Something to revisit if it crashes on giant input I guess.

Finally, I had trouble locating the libgfortran.a library and convincing MATLAB’s Mex to use it. Therefore, I added:

[~,libgfortran] = system('gfortran -print-file-name=libgfortran.dylib');
libgfortran = libgfortran(1:end-1);

to my Mex script so that I can issue lines like this:


This is enough to compile all of the fortran source files one by one and then link them during compilation and linking of the fmm3d_r2012a.c file.

I’ve added a matlab/compile.m script to my GitHub mirror/fork of the fmmlib library. So if you do the steps above you should be to just issue:

cd ~/Downloads
git clone 
cd ~/Downloads/fmmlib3d-1.2/matlab/


Mex wrapper for graph segmentation

Thursday, May 4th, 2017

I wrote a small mex wrapper for the graph segmentation part of the “Graph Based Image Segmentation” code. Most of the previously matlab implementations/wrappers worked on images. I want to apply this to geometry so I needed access to the graph segmentation directly. Here’s the wrapper (soon to be part of gptoolbox):

// mexopts = gptoolbox_mexopts('Static',false,'Debug',true);
// mex('segment_graph.cpp',mexopts{:});
#ifdef MEX
#  include <mex.h>
#  include <igl/C_STR.h>
#  include <igl/matlab/mexErrMsgTxt.h>
#  undef assert
#  define assert( isOK ) ( (isOK) ? (void)0 : (void) ::mexErrMsgTxt(C_STR(__FILE__<<":"<<__LINE__<<": failed assertion `"<<#isOK<<"'"<<std::endl) ) )
#include "segment-graph.h"
#include <igl/matlab/mexErrMsgTxt.h>
#include <igl/matlab/parse_rhs.h>
#include <igl/unique.h>
#include <igl/matlab/prepare_lhs.h>
#include <igl/matlab/requires_arg.h>
#include <igl/matlab/validate_arg.h>
#include <igl/matlab/MexStream.h>
#include <Eigen/Sparse>
void mexFunction(
 int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
  using namespace igl::matlab;
  using namespace Eigen;
  using namespace std;
  igl::matlab::MexStream mout;        
  std::streambuf *outbuf = std::cout.rdbuf(&mout);

  mexErrMsgTxt(nrhs>0,"Too few inputs");
  mexErrMsgTxt(mxIsSparse(prhs[0]),"Matrix should be sparse");
  const mxArray * mx_data = prhs[0];
  const int m = mxGetM(mx_data);
  const int n = mxGetN(mx_data);
  mexErrMsgTxt(n == mxGetM(prhs[0]), "Matrix should be square");
  assert(mxGetNumberOfDimensions(mx_data) == 2);
  // TODO: It should be possible to directly load the data into the sparse
  // matrix without going through the triplets
  // Copy data immediately
  double * pr = mxGetPr(mx_data);
  mwIndex * ir = mxGetIr(mx_data);
  mwIndex * jc = mxGetJc(mx_data);
  const int num_edges = mxGetNzmax(mx_data);
  edge * edges = new edge[num_edges];
  int k = 0;
  for(int j=0; j<n;j++)
    // Iterate over inside
      //cout<<ir[k]<<" "<<j<<" "<<pr[k]<<endl;
      edges[k].a = ir[k];
      edges[k].b = j;
      edges[k].w = pr[k];

  // defaults 
  int min_size = 0;
  // Threshold 
  int c = sqrt((double)n);
    int i = 1;
      mexErrMsgTxt(mxIsChar(prhs[i]),"Parameter names should be strings");
      // Cast to char
      const char * name = mxArrayToString(prhs[i]);
      if(strcmp("Threshold",name) == 0)
        c = (double)*mxGetPr(prhs[++i]);
      }else if(strcmp("MinSize",name) == 0)
        min_size = (int)((double)*mxGetPr(prhs[++i]));

  universe *u = segment_graph(n, num_edges, edges, c);

  // post process small components
  for (int i = 0; i < num_edges; i++) {
    int a = u->find(edges[i].a);
    int b = u->find(edges[i].b);
    if ((a != b) && ((u->size(a) < min_size) || (u->size(b) < min_size)))
      u->join(a, b);

    case 1:
      plhs[0] = mxCreateDoubleMatrix(m,1, mxREAL);
      Eigen::VectorXi C(m);
      for(int i = 0;i<m;i++)
        C(i) = u->find(i);
      Eigen::VectorXi uC,I,J;
    default: break;

  delete[] edges;
  delete u;

It takes the graph as a sparse matrix and outputs the component ids:

C = segment_graph(A);

Using glfw background window in matlab mex thread

Monday, April 3rd, 2017

A while ago, I tried to get glfw playing nicely with matlab’s mex files. I didn’t quite succeed.

My current project requires “GP-GPU” programming. I’m currently using glfw’s “background window” feature to create an OpenGL context. My first tests show that matlab’s mex will play nicely if glfwTerminate() is never called:

#include <igl/opengl/glfw/background_window.h>
#include <mex.h>
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
  GLFWwindow * window;

You can compile this (on mac os x) with:

mex( ...
  '-largeArrayDims','-DMEX','CXXFLAGS=$CXXFLAGS -std=c++11', ...
  'LDFLAGS=\$LDFLAGS -framework Foundation -framework AppKit -framework Accelerate -framework OpenGL -framework AppKit -framework Carbon -framework QuartzCore -framework IOKit ', ...
  '-I/usr/local/igl/libigl//external/nanogui/ext/eigen/', ...
  '-I/usr/local/igl/libigl/include', ...
  '-I/usr/local/igl/libigl/external/nanogui/ext/glfw/include/', ...
  '-L/usr/local/igl/libigl/lib/','-lglfw3', ...

I don’t know why including glfwTerminate() causes matlab to sometimes crash. The error report is impossible to read and seems to have something to do with Quartz.

Friday, January 6th, 2017

Like clockwork, my matlab updates have gotten out of sync with Xcode updates. It seems like fixing this SDK error always requires a different hack each year. This year I got the error:

No supported compiler or SDK was found. For options, visit 

To fix it, I replaced all occurrences of 10.9 with 10.11 in /Applications/{++,}_maci64.xml

I’m still getting linker warnings:

ld: warning: object file was built for newer OSX version (10.11) than being linked (10.9)

For now, I’m assuming that I can ignore them. We’ll see how far that gets me.

Fix dyld linker errors when installing new mosek toolbox

Monday, October 3rd, 2016

Each time I upgrade my mosek library, matlab panics and can’t find it. The old solution was to monkey with the DYLD_LIBRARY_PATH in all sorts of funny places: ~/.profile, /etc/launch.d, ~/Library/LaunchAgents/environment.plist

These all worked at some point, but as far as I can tell, no longer do. They’re also the wrong way to install libraries.

Fortunately, mosek has made life easy. Just

cd /usr/local/mosek/8/tools/platform/osx64x86/bin/

This will actually fix all of the binaries and mex files using otool and install_name_tool to find dynamic libraries in their installed locations.

dyld symbol not found, matlab c++

Sunday, December 27th, 2015

I upgrade to the newest Matlab 2015b and suddenly got some unexpected runtime errors in my command line programs compiled with matlab:

dyld: Symbol not found: _mxDestroyArray
  Referenced from: /Users/ajx/./.main
  Expected in: /usr/lib/libSystem.B.dylib
 in /Users/ajx/./.main

I finally tracked this down to a problem in my DYLD_FALLBACK_LIBRARY_PATH. The path to matlab was there but after /usr/lib/ and for some reason that order was throwing off the dynamic linker. I put the matlab path first and that fixed the problem.

GLFW c++ mesh viewer from matlab with Core OpenGL

Monday, June 15th, 2015

Here’s a proof of concept mex function for matlab that passes a triangle mesh and renders it in a new window using glfw and native opengl:

// make sure the modern opengl headers are included before any others
#include <OpenGL/gl3.h>
#define __gl_h_

#include <igl/frustum.h>
#include <igl/read_triangle_mesh.h>
#include <igl/get_seconds.h>
#include <igl/matlab/mexStream.h>
#include <igl/matlab/parse_rhs.h>
#include <igl/matlab/mexErrMsgTxt.h>
#include <Eigen/Core>
#include <GLFW/glfw3.h>
#include <mex.h>

#include <string>
#include <chrono>
#include <thread>
#include <iostream>

std::string vertex_shader = R"(
#version 330 core
uniform mat4 proj;
uniform mat4 model;
in vec3 position;
void main()
  gl_Position = proj * model * vec4(position,1.);
std::string fragment_shader = R"(
#version 330 core
out vec3 color;
void main()
  color = vec3(0.8,0.4,0.0);

// width, height, shader id, vertex array object
int w=800,h=600;
double highdpi=1;
GLuint prog_id=0;
GLuint VAO;
// Mesh data: RowMajor is important to directly use in OpenGL
Eigen::Matrix< float,Eigen::Dynamic,3,Eigen::RowMajor> V;
Eigen::Matrix<GLuint,Eigen::Dynamic,3,Eigen::RowMajor> F;
void mexFunction(int nlhs, mxArray *plhs[], 
   int nrhs, const mxArray *prhs[])
//#define mexErrMsgTxt(X) std::cerr<<X<<std::endl;exit(EXIT_FAILURE);
//int main()
  using namespace std;
  igl::MexStream mout;        
  std::streambuf *outbuf = cout.rdbuf(&mout);
  // Init glfw and create window + OpenGL context
    mexErrMsgTxt("Could not initialize glfw");
  const auto & error = []
    (int error, const char* description){
  glfwWindowHint(GLFW_SAMPLES, 4);
  GLFWwindow* window = glfwCreateWindow(w, h, "OpenGL in matlab? ! ? !", NULL, NULL);
    mexErrMsgTxt("Could not create glfw window");


      int major, minor, rev;
      major = glfwGetWindowAttrib(window, GLFW_CONTEXT_VERSION_MAJOR);
      minor = glfwGetWindowAttrib(window, GLFW_CONTEXT_VERSION_MINOR);
      rev = glfwGetWindowAttrib(window, GLFW_CONTEXT_REVISION);
      printf("OpenGL version recieved: %d.%d.%d\n", major, minor, rev);
      printf("Supported OpenGL is %s\n", (const char*)glGetString(GL_VERSION));
      printf("Supported GLSL is %s\n", (const char*)glGetString(GL_SHADING_LANGUAGE_VERSION));

  const auto & reshape = [] (GLFWwindow* window, int w, int h)

    int width, height;
    glfwGetFramebufferSize(window, &width, &height);
    int width_window, height_window;
    glfwGetWindowSize(window, &width_window, &height_window);
    highdpi = width/width_window;

  // Compile each shader
  const auto & compile_shader = [](const GLint type,const char * str) -> GLuint
    GLuint id = glCreateShader(type);
    return id;
  GLuint vid = compile_shader(GL_VERTEX_SHADER,vertex_shader.c_str());
  GLuint fid = compile_shader(GL_FRAGMENT_SHADER,fragment_shader.c_str());
  // attach shaders and link
  prog_id = glCreateProgram();
  GLint status;
  glGetProgramiv(prog_id, GL_LINK_STATUS, &status);

  // Read input mesh from rhs
  const int dim = mxGetN(prhs[1]);
  igl::mexErrMsgTxt(dim == 3,
    "Mesh vertex list must be #V by 3 list of vertex positions");
  igl::mexErrMsgTxt(dim == mxGetN(prhs[0]),
    "Mesh \"face\" simplex size must equal dimension");

  V.rowwise() -= V.colwise().mean();
  V /= (V.colwise().maxCoeff()-V.colwise().minCoeff()).maxCoeff();
  V /= 1.2;

  // Generate and attach buffers to vertex array
  glGenVertexArrays(1, &VAO);
  GLuint VBO, EBO;
  glGenBuffers(1, &VBO);
  glGenBuffers(1, &EBO);
  glBindBuffer(GL_ARRAY_BUFFER, VBO);
  glBufferData(GL_ARRAY_BUFFER, sizeof(float)*V.size(),, GL_STATIC_DRAW);
  glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(GLuint)*F.size(),, GL_STATIC_DRAW);
  glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(GLfloat), (GLvoid*)0);
  glBindBuffer(GL_ARRAY_BUFFER, 0); 

  // Main display routine
  while (!glfwWindowShouldClose(window))
      double tic = igl::get_seconds();
      // clear screen and set viewport

      // Projection and modelview matrices
      Eigen::Matrix4f proj = Eigen::Matrix4f::Identity();
      float near = 0.01;
      float far = 100;
      float top = tan(35./360.*M_PI)*near;
      float right = top * (double)::w/(double)::h;
      Eigen::Affine3f model = Eigen::Affine3f::Identity();
      // spin around
      static size_t count = 0;

      // select program and attach uniforms
      GLint proj_loc = glGetUniformLocation(prog_id,"proj");
      GLint model_loc = glGetUniformLocation(prog_id,"model");

      // Draw mesh as wireframe
      glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
      glDrawElements(GL_TRIANGLES, F.size(), GL_UNSIGNED_INT, 0);


        // In microseconds
        double duration = 1000000.*(igl::get_seconds()-tic);
        const double min_duration = 1000000./60.;
  // Restore the std stream buffer Important!

Compile with something like:

mex('LDOPTIMFLAGS=','CXX=clang++','LD=clang++','-DMEX -v -largeArrayDims','CXXFLAGS=$CXXFLAGS -std=c++11','-I/usr/local/igl/libigl/include','-I/usr/local/igl/libigl/external/glfw/include','-L/usr/local/igl/libigl/external/glfw/lib -lglfw3_clang','-I/opt/local/include/eigen3/','LDFLAGS=\$LDFLAGS -framework Foundation -framework AppKit -framework Accelerate -framework GLUT -framework OpenGL -framework IOKit -framework Cocoa -framework CoreVideo', 'tsurf_opengl.cpp');

And then if you issue:

[F,V] = surf2patch(surface(16*membrane(1,10)),'triangles');
V = V*axisangle2matrix([1 0 0],pi*0.5)*axisangle2matrix([0 1 0],-0.25*pi)*axisangle2matrix([1 0 0],-pi*0.1);

You should see something like:

opengl matlab glfw There are still quite a few kinks, but it’s at least a start.

Paste directly from clipboard into matlab image array

Sunday, October 12th, 2014

I find myself often wanting to experiment with images from papers I’m reading. To load the image into matlab properly I should extract it from the pdf, save it in a file and load the file via matlab. Often I skip the first step and just take a screengrab. But I still need to create a dummy file just to load it into matlab.

Here’s a mex function to load images directly from the clipboard. It even maintains all color channels (RGB, CMYK, RGBA, etc.)

Save this in a file paste.h:

#include <cstddef>
// Get image from clipboard as an RGB image
// Outputs:
//   IM  h*w*c list of rgb pixel color values as uint8, running over height,
//     then width, then rgb channels
//   h  height
//   w  width
//   c  channels
bool paste(unsigned char *& IM,size_t & h, size_t & w, size_t & c);

and in

#import "paste.h"
#import <Foundation/Foundation.h>
#import <Cocoa/Cocoa.h>
#import <unistd.h>

bool paste(unsigned char *& IM,size_t & h, size_t & w, size_t & c)
  NSPasteboard *pasteboard = [NSPasteboard generalPasteboard];
  NSArray *classArray = [NSArray arrayWithObject:[NSImage class]];
  NSDictionary *options = [NSDictionary dictionary];
  BOOL ok = [pasteboard canReadObjectForClasses:classArray options:options]; 
    //printf("Error: clipboard doesn't seem to contain image...");
    return false;
  NSArray *objectsToPaste = [pasteboard readObjectsForClasses:classArray options:options];
  NSImage *image = [objectsToPaste objectAtIndex:0];
  NSBitmapImageRep* bitmap = [NSBitmapImageRep imageRepWithData:[image TIFFRepresentation]];
  w = [bitmap pixelsWide];
  h = [bitmap pixelsHigh];
  size_t rowBytes = [bitmap bytesPerRow];
  c = rowBytes/w;
  unsigned char* pixels = [bitmap bitmapData];
  IM = new unsigned char[w*h*c];
  for(size_t y = 0; y < h ; y++)
    for(size_t x = 0; x < w; x++)
      for(size_t d = 0;d<c;d++)
        // For some reason colors are invertex
        IM[y+h*(x+d*w)] = pixels[y*rowBytes + x*c + d];
  [image release];
  return true;

and in impaste.cpp

#ifdef MEX
#include <mex.h>
#include "paste.h"
#include <iostream>

void mexFunction(
  int nlhs, mxArray *plhs[], 
  int nrhs, const mxArray *prhs[])
  unsigned char * IM;
  size_t h,w,c;
    mexErrMsgTxt("Clipboard doesn't contain image.");
      mexErrMsgTxt("Too many output parameters.");
    case 1:
      size_t dims[] = {h,w,c};
      plhs[0] = mxCreateNumericArray(3,dims,mxUINT8_CLASS,mxREAL);
      unsigned char * IMp = (unsigned char *)mxGetData(plhs[0]);
      // Fall through
    case 0: break;


Then compile on Mac OS X using something like:

mex -v -largeArrayDims -DMEX CXX='/usr/bin/clang++' LD='/usr/bin/clang++' LDOPTIMFLAGS='-O ' LDFLAGS='\$LDFLAGS -framework Foundation -framework AppKit' -o impaste impaste.cpp

Notice, I’m forcing the mex compiler to use clang and include the relevant frameworks.

Then you can call from matlab using something like:

IM = impaste();



Compiling pardiso matlab interface finding wrong gfortran dylib

Wednesday, May 28th, 2014

I tried to compile the pardiso mex interface for matlab and got a very annoying linker error upon running:

Invalid MEX-file '/Users/ajx/.../pardisoinit.mexmaci64':
dlopen(/Users/ajx/.../pardisoinit.mexmaci64, 6): Symbol
not found: __gfortran_transfer_array_write
  Referenced from: /usr/local/lib/libpardiso500-MACOS-X86-64.dylib
  Expected in: /Applications/
 in /usr/local/lib/libpardiso500-MACOS-X86-64.dylib

The problem seems to be that matlab is finding gfortran.3.dylib in its own directory path rather than the one that pardisoinit was linked to. These libraries are also unfortunately different. I think there’s an otool/install_name_tool trick for this, but so far I’m using this hack. I replace the libgfortran.3.dylib in Matlab with the one from gcc:

mv /Applications/ /Applications/
cp /opt/local/lib/libgcc/libgfortran.3.dylib /Applications/

So far this hasn’t messed up anything else in MATLAB, but I guess, without knowing better, it’s only a matter of luck. Too bad pardiso doesn’t seem to support mac and isn’t open source.

Matlab’s mex can’t find std headers

Friday, April 18th, 2014

Trying to compile the ecos mex files I ran into the following errors:

In file included from /opt/local/lib/gcc47/gcc/x86_64-apple-darwin13/4.7.3/include-fixed/syslimits.h:7:0,
                 from /opt/local/lib/gcc47/gcc/x86_64-apple-darwin13/4.7.3/include-fixed/limits.h:34,
                 from ../external/SuiteSparse_config/SuiteSparse_config.h:45,
                 from ../external/ldl/include/ldl.h:11,
                 from ../external/ldl/src/ldl.c:157:
/opt/local/lib/gcc47/gcc/x86_64-apple-darwin13/4.7.3/include-fixed/limits.h:169:61: error: no include path in which to search for limits.h
In file included from ../external/ldl/include/ldl.h:11:0,
                 from ../external/ldl/src/ldl.c:157:
../external/SuiteSparse_config/SuiteSparse_config.h:46:20: fatal error: stdlib.h: No such file or directory
compilation terminated.

    mex: compile of ' "../external/ldl/src/ldl.c"' failed.

Turns out this has nothing to do with ecos, rather I had upgraded my OS since installing matlab. I need to replace 10.7 with 10.9 in my /Applications/ file. Then everything compiled fine.

The offending flags were:

-isysroot /Applications/ -mmacosx-version-min=10.7

And the correct versions were:

-isysroot /Applications/ -mmacosx-version-min=10.9