MCR Installation - matlab

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.

Related

Building an entirely installation-free Windows standalone via Matlab Compiler

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.

MATLAB compiled code under mac OS X

I'm having some issues with a MATLAB compiled code under mac. I've tested the same program under windows and linux aswell with NO issue at all.
My program needs two folders to work properly, but it seems that mac doesn't like them, because it can't see them. On the contrary win and linux have no problem seeing and using that folders.
I just want to underline that I obviously put these folders in the deploytool package before creating the package.
Any idea?
Maybe I'm running the program unproperly setting the environmental variables in an unproper way.
edit:
matlab error just after the program has started.
Warning: Name is nonexistent or not a directory: materials
but materials folder is in my "current directory" and I did put that in the deploytool folder too, why it can't see that? It seems an addpath error, but why it doesn't appear under linux and windows?!
Here are a few things to think about:
Have you set your permissions to the folders correctly? I would assume the permissions for OSX should be the same as you used in Linux, but perhaps you forgot to update them after you created the folders?
Is Matlab running as the user you think it is? I don't know about Matlab specifically, but its possible it runs as a particular user depending on the environment you are in.
Is your error definitely that the folders are not found? Sometimes errors regarding disk IO are vague or misleading (like when due to permissions - see point 1 and 2).

Running Matlab MCR and MATLAB on the Same Machine

I'm having trouble getting a compiled .exe file to run with MCR instead of Matlab (I can tell because the program is using multiple threads, which it would not do if it were running with MCR). The MATLAB documentation (http://www.mathworks.com/help/toolbox/compiler/f12-999353.html) says:
"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."
Can anyone connect the dots a bit more for me? I don't know what this means. Thanks!
I had the same problem: my compiled code was multithreaded, which I did not want.
The problem got solved by compiling with the option:
-R -singleCompThread
You need to set properly the PATH global environment variable in Windows. How you do it exactly depends on Windows version.
Here is the first link from Google by query "set path on Windows": http://www.computerhope.com/issues/ch000549.htm
This variable is a list of directories. Make sure you have a directory with MCR executable earlier in this list than a directory with MATLAB executable.

Runtime error for MCC compiled program using parfor

I have problems running a program compiled with MCC that uses parfor. The non-compiled .m version works (no bug). When I run the compiled version, I get
"distcomp.remoteparfor" is undefined. I believe I exactly have the error described in
the following link.
http://www.mathworks.com/support/solutions/en/data/1-PAHWE/index.html?product=CO&solution=1-PAHWE
However, since MCR is not installed on my machine (got Matlab and MCC),
I am wondering what the pathes $APPNAME_mcr/java/jar/toolbox and
$MCR/MATLAB Component Runtime/v70/java/jar/toolbox correspond to. I found
the distcomp.jar file in C:\Program Files\MATLAB\R2011b\java\jar\toolbox, but I don't know where to put it since see any path corresponding to $MCR/MATLAB Component Runtime/v70/java/jar/toolbox since MCR is not installed.
Thanks a lot!
Fred
No need to install the MCR if you are simply trying to run the application on the same machine that has MATLAB. The question to ask is, HOW are you launching the compiled application? From a DOS command window? From within MATLAB using the SYSTEM command?
If you are launching the application from a DOS / UNIX command line, then the important thing to keep in mind is that the MATLAB binaries need to be on your system path i.e. just make sure:
$MATLABROOT\bin\$ARCH
is on your system path. Where $MATLABROOT is the matlab installation folder, and $ARCH is your system architecture. For example:
c:\work\matlab\bin\win64
on my machine since my installation folder which contains MATLAB is:
c:\work
and i am on a win64 machine.
The problem is solved. The solution is to make the program
a function instead of a script :
http://www.mathworks.com/matlabcentral/answers/22825-parfor-errors-when-file-is-compiled

Is there a quick method to restore the PATH environment var settings for MATLAB?

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.