0

I have created a MEX file using MATLAB's Coder toolkit, and it works perfectly fine on my computer, however, when I sent it to someone else for their use, it error and would not work.

What are the proper steps for properly distributing and allowing others to be able to use my MEX file/code?

On a side note, (im not sure how much this affects my issue) but in the C code file that the coder created, it has variables that lead to directories on my computer, instead of having relative pathing.

Amro
  • 123,847
  • 25
  • 243
  • 454
G Boggs
  • 381
  • 1
  • 6
  • 19
  • 1
    are you giving them the compiled MEX-file or the source C code? MEX-files are binary shared libraries, and must be compiled on the target platform to produce the right executable (Windows, Linux, OSX) – Amro Nov 06 '14 at 20:54
  • How do you generate the MEX and what error message do you get when trying to run it on a different computer? Normaally, you don't need anything other than the generated MEX file (I think), but you should probably fix the directories issue before distributing the MEX file. However, as @Amro pointed out, you can only use MEX files within MATLAB, so the client computer must have MATLAB installed. – am304 Nov 06 '14 at 21:03
  • 1
    Are the architectures of your machine and your colleague's machine the same? For MATLAB Coder generated MEX files, the MATLAB release your colleague is using should be at least as new as the release used to generate the MEX file. The explicit errors encountered would also be extremely helpful. – Ryan Livingston Nov 07 '14 at 07:25

1 Answers1

0

Installing the MCR (my original advice) only applies to compiler generated code, although you still need a compatible libmx and libmat. I thought perhaps they could get a hold of them through the installer, but they'd really need to update MATLAB if it were incompatible (v6 vs v7).

In general, avoid paths in your deployed code.

chappjc
  • 30,359
  • 6
  • 75
  • 132
  • 1
    The OP is using MATLAB Coder not MATLAB Compiler. Coder creates C/C++ source code that has no dependencies on MCR. – Amro Nov 06 '14 at 20:51
  • @Amro It still needs the libmx and libmat shared libraries at a minimum. (In which case my answer is still wrong now that i think of it). The functions themselves are surely independent though... – chappjc Nov 06 '14 at 20:52
  • ok, but you can't run MEX-functions outside of MATLAB. The MCR is only used to run deployed (think packaged) applications where MATLAB is not available. Obviously you can't have MEX-files without the necessary MX/MEX libraries. – Amro Nov 06 '14 at 20:58
  • @Amro That's right about the MCR but i was thinking library dependencies... Poor solution i agree. – chappjc Nov 06 '14 at 21:03
  • MathWorks has somewhat maintained binary [ABI](https://en.wikipedia.org/wiki/Application_binary_interface) [compatibility](http://en.wikipedia.org/wiki/Binary_code_compatibility) of the MEX/MX libraries (at least the publicly exposed functions), that's why you can compile a MEX-function from an old version and would still work in a newer MATLAB version without recompilation (of course assuming the same platform, Windows/Linux/Mac). The one time I think they broke compatibility was when they moved from MATLAB v6 to MATLAB v7, and required MEX-files to be recompiled – Amro Nov 06 '14 at 21:03
  • @Amro I can say from experience this is not always correct. Between major releases (6 -> 7) things break, usually not between point releases. – chappjc Nov 06 '14 at 21:05
  • yes, but between v7.x and v8.x binary compatibility was maintained – Amro Nov 06 '14 at 21:07
  • @Amro I believe you, but is that documented? – chappjc Nov 06 '14 at 21:10
  • they have cleverly designed the `mxArray` type as an [opaque](https://en.wikipedia.org/wiki/Opaque_data_type) pointer, that way they can make internal changes without breaking ABI. I can't find MATLAB documentation on this right now, but here is a page about a similar design in Qt library: http://qt-project.org/wiki/Dpointer – Amro Nov 06 '14 at 21:13
  • For example, you can [see here](http://undocumentedmatlab.com/blog/matlabs-internal-memory-representation) that the hidden layout of the `mxArray` structure has slightly changed between releases, but it maintained its size allowing MEX-files (that dynamiclly link against LIBMX) to still work without recompilation. – Amro Nov 06 '14 at 21:17
  • @Amro Ahh, so i bet they've padded it's members, vtable, whatever, so they can modify it's functionality without issue. Very nice idea. I thought they just made it opaque to hide how it really works and prevent rampant abuse/misinterpretation of the type. – chappjc Nov 06 '14 at 21:23
  • that too :) opaque types [serve two purposes](http://stackoverflow.com/a/7553775/97160): implementation hiding and easier binary compat. You see the whole MEX thing is really C++ underneath, just exposed as a C interface with functions that take an opaque `mxArray*` pointer, and internally call member functions of some C++ class after casting the pointer: http://blog.aaronballman.com/2011/07/opaque-data-pointers/ – Amro Nov 06 '14 at 21:30