I want to use the export_fig package for Matlab. At one point this worked, but now it's broken. The error occurs here:
>> system('pdftops -h')
dyld: Library not loaded: /opt/local/lib/libtiff.5.dylib
Referenced from: /opt/local/bin/pdftops
Reason: Incompatible library version: pdftops requires version 8.0.0 or later, but libtiff.5.dylib provides version 6.0.0
pdftops -h: Trace/breakpoint trap
But when I call pdftops from my own bash terminal everything works fine. I suppose it must be because Matlab has some bad library paths or something, but I don't know where to go from here?
Some relevant environmental vars used by matlab:
>> system('env')
SHELL=/bin/bash
OSG_LD_LIBRARY_PATH=/Applications/MATLAB_R2013b.app/sys/openscenegraph/lib/maci64
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin
__CHECKFIX1436934=1
XFILESEARCHPATH=/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/locale/%L/%T/%N%S:
DYLD_FRAMEWORK_PATH=/Applications/MATLAB_R2013b.app/sys/os/maci64:/Applications/MATLAB_R2013b.app/bin/maci64/../../Contents/MacOS:/Applications/MATLAB_R2013b.app/bin/maci64:/Applications/MATLAB_R2013b.app/extern/lib/maci64:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./native_threads:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./server:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./lib/jli
SHLVL=1
__KMP_REGISTERED_LIB_33586=0x124404710-cafeb339-libiomp5.dylib
DYLD_LIBRARY_PATH=/Applications/MATLAB_R2013b.app/sys/os/maci64:/Applications/MATLAB_R2013b.app/bin/maci64/../../Contents/MacOS:/Applications/MATLAB_R2013b.app/bin/maci64:/Applications/MATLAB_R2013b.app/extern/lib/maci64:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./native_threads:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./server:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./lib/jli
If you take a look at the error message, MATLAB uses libtiff to call pdftops, but only has version 6.0.0. It says it needs version 8.0.0 or later. There has been a case where this happened before here on StackOverflow. Someone was trying to install mexopencv and has encountered the same error that you're talking about: Compiling mexopencv in OS X 10.9 with Xcode 5 and Matlab R2013b
Though this is unrelated to what you're doing, they encountered the libtiff error that you speak of. They provide two solutions how to fix this error:
Go into MATLAB's root directory, then go bin/os directory where os is the directory of the operating system you are using (in my case, it's maci64). To get into the root directory, in the command prompt do this: cd/(matlabroot). Once you're here, locate the libtiff.5.dylib file and rename it to something like libtiff.5.dylib.bak so that the libtiff libraries that are used are the ones that are default to your system rather than what MATLAB is using internally in the program.
Force MATLAB to point to the library that is part of the system rather than using the one built into MATLAB. As such, in MATLAB's command prompt, run this command:
setenv('DYLD_INSERT_LIBRARIES','/opt/local/lib/libtiff.5.dylib');
Once you do this, you may get further errors that are similar but are with other libraries. As such, you need to keep appending these libraries in the second parameter of setenv and colon-delimiting them until you resolve the issues. You need to make sure that you're pointing to the ones on your system rather than the ones installed with MATLAB. In your case, you have to do:
setenv('DYLD_INSERT_LIBRARIES', ...
'/opt/local/lib/libtiff.5.dylib:/opt/local/lib/libcurl.4.dylib');
Glad this helped!
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.
I have compiled Mex file successfully on my laptop. But when I am running it, it says Invalid mex file 'c:\newfolder\filename.mexw32' The specified module could not be found.
System specification:
OS: windows 7
MATLAB 2010a
Microsoft Visual Studio 2008.
The same mex file is compiled and run successfully on my PC under XP SP3.
This MathWorks support link suggests two possible reasons to your problem:
You do not have all of the necessary libraries that the MEX-function is dependent upon.
You are running a MEX-file on a different version of MATLAB than it was compiled on.
Either way, to locate the source of this error it says that you need to list all dependent library files and verify their existence in the system you're trying to run the MEX file on, and also recommends the Dependecy Walker as the tool to to do that.
Do you you the mex file on another system than the one it is created on?
If so, then you need to install the Microsoft Visual C++ Redistributable on that machine.
I had this problem also when upgrading from Matlab2010a/VS2008 to Matlab2013a/VS2010.
All my environment variables were sent correctly.
A reboot fixed problems with OpenCV dlls not being found, I assume that it was still trying to link to the OpenCV dlls for VS2008 (even though I had changed the path). However still my mex file could not find libmex.dll.
When I installed Matlab2013a, I did not uninstall the old version (in case I wanted to go back).
However that was the cause of my problem.
Once I uninstalled the old version of Matlab and rebooted again, the problem was gone.
I had a similar problem. I was only linking against 1 'lib' so I simply copied that lib into the same folder as the mexw64 and it worked.
I have not poked around for the correct place to tell MATLAB to add the lib's real location to whatever path it's looking at.
I'm trying to deploy an application from Matlab to JAVA.
I use Matlab Builder JA and the Image Processing Toolbox.
I create my jar file from Matlab R2012a with the deploytool on MacOSX.
When I run my JAVA program using this jar on my mac, it's OK, but when I try to run it on a Linux or Windows system, I get the error:
Undefined function or variable 'ipplmex'.
Error in ==> ippl at 48
Error in ==> imrotate>useIPP at 205
Deactivating the use of IPPL with iptsetpref('UseIPPL', false) doesn't fix my problem.
I also have done the exact same work on a Linux environment with Matlab R2011a, and it works on Linux but not on a MacOSX machine with the same error.
If anyone has an idea concerning this IPPL thing when changing OS, that would be great.
Thanks !
Java components created with Builder JA are only cross-platform if they don't depend on platform-specific libraries, such as MEX-files you create, or the IPPL libraries supplied with Image Processing Toolbox.
If you want your Java component to make use of IPPL, I think you'll need to create the Java component once on Mac, once on Linux, once on Windows, and use the version created on the appropriate platform.
ipplmex is a (platform-specific) MEX file that is called by ippl, which is a utility function that checks whether IPPL is available. I can't check this at the moment, but I think it makes that availability check whether or not you've specified that you want to actually use IPPL, via the iptsetpref command. Therefore whether or not you specify that IPPL should be used, there's still a platform-specific MEX-file being called.
Again, I can't check this at the moment, but if you're comfortable with your component not using IPPL, you might try to modify the ippl command to just return zero (indicating that IPPL is not available) without attempting to execute ipplmex. (Make sure to take a copy of your existing ippl.m file before you try any modifications).
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.