"Invalid MEX-file" when using curve fitting toolbox compiled

I use mbuild and mcc in a Makefile to compile some matlab functions into one shared lib and some wrapper code (C) into another shared lib. I've now added a function that uses 'fit' and it compiles, but I get this error message when it is called:

Error using fit>iFit (line 414)
Invalid MEX-file
'/usr/local/MATLAB/R2011b/toolbox/compiler/mcr/matlab/sparfun/etree.mexa64':
libmwarpack.so: cannot open shared object file: No such file or directory

Error in fit (line 109)

No amount of trying to explicitly chuck in the kitchen sink in the Makefile ultimately resolves this (e.g. explicitly adding -lmwarpack results in another error, tackle that and you get another). I resorted to trying to compile using deploytool and that can't find the runtime when you try to call it. I'd really prefer to use the Makefile route. Searching for help has come up with the closest match that this error means the toolbox (MEX file) was compiled using a different version of matlab. But I don't get how that can be. Toolbox is version 3.2. I get an error both using 2010bSP1 and 2011b.

Answer 1

[Kaustubha Govind]

The issue is related to runtime, so it seems like more of a path issue, than a compile/link-time issue. Did you say that deploytool fails at compilation? If yes, perhaps the issue is with your MATLAB installation? Are you able to execute the MATLAB code from the MATLAB prompt? Also, please verify if the library exists in /usr/local/MATLAB/R2011b/bin/glnxa64. Does it also exist in the corresponding folder under the MCR installation root on the deployment machine?

[Guy]

Hi Kaustubha,

The compilation succeeds without error using both methods. The deploytool issues some warnings about adding my local source path. It does this a number of times and then also warns that it's adding a duplicate path (as it adds the same source path to the matlab instance a number of times). I previously had to define the LD_RUN_PATH environment variable to the path for the runtime (/usr/local/MATLAB/R2011b/runtime/glnxa64:.) in my Makefile. I would have thought that matlab's own deploytool would take care of this; it clearly doesn't and I'm not sure why not as it can easily be defined at build time (as I do). I've tried using the deploytool to compile my .m files and then compiling and linking my wrapper functions with that shared object. This also throws the same error, despite the .../bin/glnxa64 path being passed in the CLIBS variable in the mbuild options file. Of course this only applies to what I'm compiling myself.

The code runs from the matlab environment.

Anyway, back to the nub of the issue. I can get it to work by adding the .../bin/glnxa64 path to my LD_LIBRARY_PATH. This is clearly an undesirable hack, but I can't find any other way around it. It looks, to me, like etree.mexa64 (in /usr/local/MATLAB/R2011b/toolbox/compiler/mcr/matlab/sparfun/) is not properly linked and doesn't look in the .../bin/glnxa64 directory at runtime. Short of recompiling the binaries I can only think I'm stuck with the LD_LIBRARY_PATH cludge.

[Kaustubha Govind]

Guy: I think you are confusing shared libraries (.so files) with the import libraries needed by DLLs on Windows. Shared libraries are not required at link-time at all, they are only needed at runtime where they are loaded using dlopen). So adding them to the makefile does not help anything. The only thing that is needed is that the MCR library path be added to the system path. See http://www.mathworks.com/help/toolbox/compiler/bqrw460-1.html#bqrw5ck-2 for path settings needed by deployed applications (matlabroot must be replaced with mcrroot where MCR is installed).

Typically, this path is updated automatically by the MCR installer on the deployment machine, but sometimes it may fail to do so (especially if it does not have administrative privileges).