My m file was compiled by MATLAB R2008b. When I distributed it to others, their PC seem to lack certain DLL (mclmcrrt79.dll). Thus, I was looking for MCR7.9 but couldn't find any official copy. I did find some on the web: MCR7.9 download but am not sure whether it is safe to be installed. Is it OK to use this copy or is there any official MCR7.9 available?
Since R2012a, the MCR for each version of MATLAB has been available as a download from MathWorks.
Versions of the MCR prior to R2012a are not distributed in the same way by MathWorks, and should be distributed by the developer of the application along with the compiled component directly to end users. If you are the developer, you should distribute it along with the component - specifically, you should send them the MCR installer (you have this - it's in \toolbox\compiler\deploy\<ARCH>, where <ARCH> is your platform).
In fact, in R2012a there was a license-related change: for versions prior to that, you're not actually allowed to make the MCR (or the installer) available as public download (so the people who are making it available at the SourceForge site you link to are, strictly speaking, in breach of the license).
One other confusion may be causing you difficulty: R2008b is MATLAB version 7.7. MATLAB version 7.9 is R2009b. You need to make sure that you use the right version of the MCR for the version of MATLAB you used to compile.
For reference, I solved the problem related to "My Own Exception: Fatal error finding symbol mxCalcSingleSubscript_700 in D:\XYZ\libmx.dll Error:" It was done by sending libmx.dll to the user. The file is stored at \MATLAB\bin\win32\
Related
I am trying to load a 3rd-party library (.so file) into MATLAB under RHEL.
I am getting an error: undefined:symbol: _intel_fast_memmove.
From Symbol lookup error: _FileName_: undefined symbol: _intel_fast_memmove it seems like I need to add a sub-directory of /opt/intel to my LD_LIBRARY_PATH environment variable, but I don't have an /opt/intel directory.
UPDATE:
MATLAB said that the problem came when trying to load libifcoremt.so.5. I have since installed Intel's Redistributable Libraries and all that did was call Intel's version of libifcoremt.so.5 but still looked for _intel_fast_memmove (but still didn't find it). So now I'm thinking that there must be some other "definitions" file somewhere that I'm missing.
It took me a few days, but I was able to figure out what was going on.
In the end, there were two problems:
I was missing some libraries -- not the ones that I mention in my question, but Intel's Redistributable Libraries.
Even with all of the libraries on my computer, MATLAB was still using an older version of the some of the .os files.
I failed to mention in my question that while the 3rd-party library is fairly recent, I was calling it from MATLAB 2012B because I needed to integrate it with a software package that doesn't work correctly with later MATLAB versions. My apologies for that omission -- it turns out to be a critical piece of the puzzle.
While diagnosing this issue, I learned that MATLAB has it's own copy of the Intel libraries in the <MATLAB>/sys/os/glnxa64 sub-directory and that it creates an internal version of LD_LIBRARY_PATH that points to its internal version before the LD_LIBRARY_PATH that it imports from the Linux OS. Since the version of MATLAB I'm using is 6 years old, so is it's Intel library, which doesn't contain some symbols defined in the new library, such as intel_fast_memmove.
To get the integrated system up and running, I instituted a workaround to rename the sys/os/glnxa64 before calling the 3rd-party library so that MATLAB found the newer Intel library instead of the MATLAB 2012B version. And then named it back when done (without that directory, MATLAB won't start).
Note: I first tried editing the value of LD_LIBRARY_PATH inside MATLAB 2012B to prefer the new Intel library, but found that even though the external variable value changed, loadlibrary still used the original value that placed MATLAB's library first on the path.
My client has a network that doesn't have access to the internet. They intend to buy (very few) Matlab licenses just for the development efforts of me and my colleague. For the operational use by their staff, however, I should compile my Matlab code to *.exe files so that the operators don't use up licenses just to execute my Matlab "app"/"solution" (the language seems to be changing these days). They won't actually have mcc licenses, so the compiling will be done on my home organization's network.
The problem is that when the compiled executable runs, there doesn't seem to be an obvious way to force it to use Matlab Compiler Runtime (MCR). If there are Matlab licenses on the target system, it can use that as well. The whole point of compiling, however, is to avoid using the few licenses on the client network so that the licenses are available for m-file development work when needed. So the unique feature about this situation seems to be that the target environment will eventually have both Matlab licenses and MCR, as well as the requirement that compiled executables use only the MCR rather than the Matlab licenses.
The Mathworks is looking into the problem, but prospects of finding a solution are unclear. I am hoping that it won't involve manual rejigging login scripts to customize environment PATH variables, as that will break whenever login scripts are updated. I'm hoping for a solution like a pragma-like statement in the top-level m-file, or an mcc switch. In perusing the mcc documentation, however, no switches present themselves as likely candidates except for -Y license.lic, and it's not clear how to use that.
With regard to the client, another limitation I face is that I don't want to pester them with trial-and-error (it's not their job). This is complicated by the fact that there is also no efficient way to convey electronic content to them, so quick, iterative trial-and error is out. As well, their target environment, with Matlab licenses, doesn't yet exist, though the process to get there is in the works. It's a bit of an chicken-and-egg problem; they are getting Matlab based on the assumption that we can find solutions for the challenges, but it's hard to derisk the assumption beforehand by investigating solutions when the target environment doesn't yet exist.
On my home organization's system, I also face the limitation that I don't have rights to install MCR. Hence, I can't undertake trial-and-error to identify an incantation or recipe that ignores the presence of Matlab licenses and forces the use of MCR. Not that I have the time to do that, as it is a very inefficient way to achieve this objective.
Because of the many circumstantial challenges, trial-and-error isn't the way to go, and I'm hoping there is a canned method for forcing the use of MCR over any Matlab licenses that might be present. I am using R2015b.
I am working with this exact deployment situation for OS X / Linux with Matlab 2015b. When you compile an application for a Unix-based OS, the compiler creates a shell script that is executed at startup. My solution is to modify this script to check for the presence of the runtime libraries. For example, on OS X (macOS):
echo "Setting up environment variables"
if [ -d "/Applications/MATLAB/MATLAB_Compiler_Runtime/v90" ] ; then
echo "Using MCR v8.6 (R2015b) (_Compiler)"
MCRROOT=/Applications/MATLAB/MATLAB_Compiler_Runtime/v90
elif [ -d "/Applications/MATLAB/MATLAB_Runtime/v90" ] ; then
echo "Using MCR v8.6 (R2015b)"
MCRROOT=/Applications/MATLAB/MATLAB_Runtime/v90
elif [ -d "/Applications/MATLAB_R2015b.app" ] ; then
echo "Using MATLAB R2015b application"
MCRROOT=/Applications/MATLAB_R2015b.app
else
echo "No MATLAB libraries found! Install MCR R2015b from:"
echo " http://www.mathworks.com/products/compiler/mcr/"
echo " "
sleep 10
exit
fi
TMW's response:
Running a standalone application built with MATLAB Compiler will not check out any licenses whether running against an installed MATLAB Compiler Runtime or the runtime installed as part of a MATLAB Compiler installation. Note that end users with MATLAB installed without MATLAB Compiler will not have the compiler runtime libraries included with their installation.
If you have installed the MATLAB Compiler Toolbox, MATLAB will have a "runtime" folder with the necessary DLLs to execute the standalone application. Without the MATLAB Compiler Toolbox, these DLLs will not be available. Instead the user must install MCR to run the standalone application...the user cannot forgo the installation of MCR if they do not have the MATLAB Compiler Toolbox installed and they wish to run the standalone application.
I'm encountering a serious problem while trying to deploy a Matlab program as a stand-alone for Windows.
My end users are employees in some corporation and have only access to static computers. While they can download, unpack and execute stuff, they don't have installation privileges, so they're unable to install the Matlab Compiler Runtime (MCR). Unfortunately, they need MCR in order to run my deployed/compiled Matlab program. The deploytool offers me the option to "include MCR in the package", but it doesn't really do that. Instead, it packages the MCR installer, which is useless in my case as described above.
So how can I create a stand-alone application that runs on Windows out of the box, even without MCR installed and without installing it first? There has to be a way to compile this all the way down to binary...
You can't run Matlab code standalone without having MATLAB or the MATLAB Compiler Runtime installed. But it is legal to distribute the MCR to the customers to make them able to use your programs.
Alternatively you can use the MATLAB Coder to convert your code to C/C++, which is not completely issue-free, as just a subset of the Matlab language is supported.
Have a look at this question for the differences between MATLAB Coder and MATLAB Compiler.
Just ask IT to install the MCR, that only needs to happen once. After that the users should be able to execute your programs.
Note: There is a reason that the MCR needs to be installed, and can't just be executed. Therefore I don't expect there to be a 'trick' to avoid this.
So I have a MATLAB program that I made and compiled in Matlab R2011b. Now I want to distribute the compiled version. I understand the user will have to install MCR on their computers to run my program. My question is: will it make a difference if this user already has some other version of MATLAB installed on his system. I checked MATLAB help and this was written
"Windows. To run deployed components against the MCR install, mcr_root\ver\runtime\win32|win64 must appear on your system path before matlabroot\runtime\win32|win64.
To run deployed components against the MCR install, mcr_root\ver\runtime\win32|win64 must appear on your system path before matlabroot\runtime\win32|win64.
If mcr_root\ver\runtime\arch appears first on the compiled application path, the application uses the files in the MCR install area.
If matlabroot\runtime\arch appears first on the compiled application path, the application uses the files in the MATLAB Compiler installation area."
So does each user has to change his system paths as instructed or will my program work even without this change?
Yes, if the target machine has a version of Matlab installed things will likely not work as expected. I say likely as if you have the the same version of Matlab installed on the target machine some things might work ok.
To avoid all of this you must ensure the MCR appears first on the path.
To run the application on the MCR on your local development machine you should make sure the MCR path appears before Matlab's path.
I can talk just from the viewpoint of my own experience:
Part 1, matlab + MCR of the same version
I think, this is just a recommendation... I never cared about it, and I never had problems with it...
It would work, and you, most probably, won't notice any difference.
I've just changed those records in PATH upside-down, and my compiled app is still working.
Part 2, several MCRs of different version
Multiple MCRs, say, R2010b and R2012b won't interfere. Tested 100+ times. So, unexperienced end user, who don't have Matlab, won't have to edit PATH.
I seem to have wiped out my path environment variable a while back. I've been slowly restoring things. I have both MATLAB and the MATLAB compiler installed. DLL's I've created from the MATLAB compiler won't run because they can't find the MATLAB compiler runtime dlls. While I did find the particular files that are my immediate problem. I'm wondering if there is a MATLAB *.bat file or command I can type that will restore my path variable to what it was after MATLAB and the Compiler were installed. I'm hoping to forestall future problems.
In case it's version specific I'm running MATLAB R2010b, I'm running a 32 bit version on a 64 bit machine.
[Edit]
I thought I would add that the path I need for running the compiled version was:
C:\Program Files (x86)\MATLAB\MATLAB Compiler Runtime\v714\runtime\win32
With luck, that one along with the two suggested in the answer will get me back to the original state.
restoredefaultpath might recover your MATLAB installation. Consider the use of startup.m, in order to easily undo changes to your environment.
You want to have these two directories on the PATH (I think the order is important):
C:\Program Files\MATLAB\R2010b\runtime\win32
C:\Program Files\MATLAB\R2010b\bin
Obviously you need to adjust the path to match your setup and architecture (those are on a WinXP 32-bit)
If you have a current software maintenance contract for your MATLAB, it may well be that the easy thing to do is just upgrade to the next version of MATLAB since R2011a is out now (unless there is some compelling reason why you must develop on R2010b. Running the software installer should recreate the default environment for MATLAB. I am, of course, assuming that you have Administrator access on your PC and have permission to install software.