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).
Related
On Windows, trying something with gtk+. I have downloaded Msys2, along with gtk+3.0.
Successfully compiled all the gtk+3.0 examples in the msys2 mingw-w64 terminal.
Now I want to move a bit further to try work without the msys environment.
I opened up cmd and navigated to where the example executables are compiled. Then I fired them up by typing "example.exe".
libgio-2.0-0.dll missing, not surprised. I go back to check the PATH environment of the msys environment, PATH=/mingw64/bin/:/usr/local/bin:/usr/bin/:/bin:/c/Windows/System32:..blablabla
So in the cmd environment I did set PATH=%PATH%;pathto/mingw64/bin; and run example.exe again.
This time it gave a very strange error cannot find entrypoint inflateValidate (in dll libpng16-16.dll)
So I checked, indeed there was no inflateValidate function in the dll. it seemed to me that something thought the function is in the dll and tried to call it but because it doesn't exist so it failed. What I don't understand is that why did it not fail in the msys environment but failed in the windows environment. And does that bring any impact to me if I am going to ship any gtk application? I thought simply distributing the relevant dll would be enough.
I have tried instead of adding the mingw64/bin path to the PATH variable, but copying the required dll the the execute location 1 by 1, but at the end it still gave the same error.
I have also tried to search for other libpng*.dll in my computer, none of them contained the inflateValidate function.
If anyone know whats going on please shed some light to the question.
I might be very late to the party but I ran into the same issue yesterday (missing the inflateValidate symbol) and after checking the contents of the zlib1.dll file could ascertain that the function is just not there.
I downloaded another version (specifically this one https://sourceforge.net/projects/uqm-mods/files/latest/download, though I am in no way affiliated to this project) and saw that the inflateValidate symbol was indeed declared, so I suppose that the zlib bundled with your files is not up to date with the libpng requirements.
This solved my problem. I hope it solves yours too.
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'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.
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
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.