Mixing compiled matlab shared libraries with mex code.

I have some matlab code that invokes mex code (compiled with VS2013). I have both Debug and Release builds of the mex code, and can adjust my system (windows) PATH prior to starting up Matlab so that when I invoke that mex function from Matlab, it invokes the desired build configuration.

Now, I want to bundle up the matlab code into a DLL with the matlab compiler. If I don't add the mex DLLs as additional files required in the .PRJ GUI, the compiled matlab code can't find it at runtime. But if I do add the mex code, the resulting compiled matlab library is "build configuration dependent" -- i.e. if I added the debug build of the mex code, the library won't work from a release build of an executable program client of the compiled matlab library, and vice versa. So, what I want to do is to get a compiled matlab library that doesn't know about the mex code, but which can find it at runtime using the normal PATH-related load procedure, since the desired mex DLL will be in the same folder (Debug or Release) as the executable program client of the compiled matlab library. But I don't seem to be able to find a way to accomplish this goal. Any thoughts?

Answer 1

[Dasharath Gulvady]

The best way to do this is to place the MEX file in a relative path to "ctfroot":

http://www.mathworks.com/help/compiler/ctfroot.html

Normally, in Windows, "ctfroot" is %temp%\username\mcrCachexx.

[Chris Volpe]

Thanks for the reply.

Well, that's pretty much what happens right now by adding the DLL to the list of additional files, no? If I do it at runtime, the main (C++) program must find the appropriate version of the DLL (by looking in the folder which contains the currently-running C++ executable) and copy it to some hardcoded location. And client code must therefore have knowledge of the internals of the compiled Matlab DLL coded within it. That's probably a less-optimal solution than building two different versions of the compiled matlab code.

Perhaps it would be better if I modified the Matlab PATH to contain the folder where the executable is stored. Then, whether I was running a Debug build or a Release build, it would find the right one. Would that work?

[Dasharath Gulvady]

You do not have to use a hardcoded location to copy the MEX file. You can set-up a Windows environment variable to point to a location where MEX file is placed. You can read the same environment variable in your MATLAB code to read the environment variable and make use of the MEX file

[Chris Volpe]

Rather than copy the mex file to the ctfroot, I have tried a different approach in which I pass, to the compiled matlab code, the path where the mex code normally gets built (which is a subfolder of where the main C++ client application gets built). In the compiled matlab code, I add this location to the matlab path with the addpath() function. Now, when I try to invoke the mex code, it finds the mex file in the correct location, but it cannot execute it. When I try, it complains: "Cannot find authentication file 'D:\Path\to\mymexfile.mexw64.auth'. I suspect it knows that I'm trying to "inject" code into the behavior of the compiled matlab DLL at runtime, and perhaps it's intentionally blocking that for security reasons.

I suspect that the underlying issue is that my mex file, call it "A.mexw64' is dependent on another library, "B.dll". But "B.dll" is also a dependency of the main executable, so when I build a particular configuration (debug or release) of A.mexw64 into the compiled matlab DLL, and the client application invokes it, the loader sees that in order to load A.mexw64, it needs B.dll, but B.dll is already loaded as part of the main client application, and the configuration of B.dll that is loaded depends on the configuration of the client executable, which may or may not be the same as that of A.mexw64. This is my dilemma. I don't think bundling the corresponding configuration of B.dll into the matlab compiler project alongside A.mexw64 will solve the problem, because Windows will probably ignore that DLL, knowing that it already as a "B.dll" loaded. I wonder if I'm just stuck building config-specific versions of the compiled matlab project.

[Adam Callens]

What about the A.mexw64.auth file that is not generated if you don't include the mex file in the mcc build. How do you get around that?

Answer 2

[Chris Volpe]

I solved my issue with a three-step process. First, I changed my VS2013 project settings for Project B such that it creates B_debug.dll and B_release.dll. Second, I added B_release.dll to the additional required files for the matlab compiler. Third, I changed my VS2013 project settings for A.mexw64 such that the target file gets built into the same folder as B.dll. I had previously set all my mex code to be built into a "MEX" subfolder so that I could add this subfolder to my Matlab path and non bog down Matlab with searching through a binaries folder that contained all sorts of 3rd-party DLLs. Putting them in the same folder ensures that when I add them both in the deploytool GUI, they'll end up in the same relative path off the expanded ctfroot temp folder at runtime, ensuring that B_release.dll can be found at runtime.