I'm trying to run a program originally tested on Matlab 6.5 on a new release (R2009a)
The program uses some mex files, and I get the following error when trying to run it:
??? Invalid MEX-file '/normalizedCut/common_files/sparsifyc.mexglx':
normalizedCut/common_files/sparsifyc.mexglx: symbol mxGetIr, version
libmx.INTERNAL not defined in file libmx.so with link time reference.
(the code I'm trying to tun is Normalized cut by Shi & Malic, and can be found here:
http://www.cis.upenn.edu/~jshi/software/files/NcutClustering_7.zip)
If I try to run the code on the same system but Matlab 2007a it runs ok.
Is there some problem with backwards compatibility for 2009a?
Are there any flags somewhere in the system I can change to help it work?
When I googled it I saw some references to the LD_LIBRARY_PATH env variable, but what exactly should be added to it I could not find out.
Thanks,
Yair
The source code for those mex functions appears to be available in the "Image segmentation with normalized cuts" source on this page: http://www.cis.upenn.edu/~jshi/software/ (in the specific_NcutImage_files subdirectory in the unpacked .zip)
It's pretty common for there to be problems running mex functions with different versions of Matlab. The errors you're getting look like they're due to API changes in Matlab (though that surprises me a little). I've had the most trouble because of binary incompatibilities induced by changes in gcc. I'd suggest contacting Jiambo and asking him if he can build a new version or release the source.
Worst case, you could try re-implementing those mex functions. The normalized cut algorithm is pretty straightforward in Matlab (see the Shi and Malik paper). By the names of the mex functions, they look like they're mostly duplicating existing matlab functionality (matrix multiplication, matrix sparsification). There's a non-zero chance that if you re-implemented them as regular m-code functions they'd be faster anyway due to the multicore support that's been added to Matlab.
Related
I have a Windows Matlab R2020a and was able to generate C source code for my Matlab function. However, I need to run a MEX file (for speed) on a Linux platform which has a Matlab installed (without Coder) and no way to install it (even trial version).
Please, provide the steps to compile this Matlab-generated C code on the linux (Ubuntu) system. I guess it can be done with gcc. I am unable to find a clear description on the web, as this process seems extremely complicated due to the obscure command line args needed to give to gcc (and i only rarely compile C code).
Please, note that generating C code using the MATLAB Coder App is not enough if you need a MEX file. MEX files have to contain a mexFunction function, which is not generated by the Coder App.
As a first step, I'd make sure your compiler is supported by MATLAB for the creation of MEX files. You can find the supported compilers on Linux here. Then I'd check whether the compiler is setup for Matlab to use it, as shown here. Finally, I'd have a look at some examples provided by Mathworks themselves: here
Once the C code (with the mexFunction) is ready, you can compile it using the mex command and use it on the Linux platform with no or minimal adjustments, depending on how heavily you rely on the functions defined in mex.h (which is the header your C file will have to import if you want to generate a MEX file).
You need the interface provided by the mexFunction for Matlab to be able to exchange inputs and outputs with the compiled function. Note that you can create other standard C functions (possibly defined in other C files) and call them from within the mexFunction as you would normally do in C. Basically, you can create your own libraries in C and then use them in Matlab via dedicated mexFunctions.
mex.h also provides the API to "convert" C data structures into Matlab data structures (e.g. arrays, cell arrays etc., all via the mxArray type).
There's a bit of a learning curve, mostly spent in understanding how to convert data back and forth between standard C and Matlab, but it's certainly worth your while. With a bit of care (e.g. switching to mxArray types only when absolutely necessary), you can end up having libraries of functions that can be used in standard C programs as well as in Matlab applications
I am struggling with MATLAB installation. At the last step, it shows the following message:
However, I have the .net and gcc compilers on my system. It is odd that it also requires MATLAB compiler. Because it should be installed with the software itself automatically. I have never faced such problems when installing earlier versions of MATLAB.
You don't face a problem at all. The installation runs smoothly and MATLAB will work perfectly. Only if you want to translate MATLAB code to C code with the Matlab Coder toolbox, you require a C compiler (such as gcc or MinGW). This is obvious. Why should MATLAB ship a C compiler if there are plenty of open-source compilers (of which you maybe have a preference?) and there is no need for MATLAB (the main product) to run it?
With Simulink it is a bit less obvious but the argument is the same (why should MATLAB ship a C compiler?). Simulink is a model-simulation tool, calling a once-defined model over and over again at fixed (or dynamic) time steps. To speed up the calculation, it actually compiles the code first (note that MATLAB mainly uses a just-in-time-compiler). Those are .mex files, which is basically compiled C code (similar to a DLL). For this, it needs a C compiler and which brings us again back to the argument of why to ship one.
To make a long story short: Don't worry. Go ahead, this is not a problem and totally normal. As you said, you already have a C compiler installed (gcc), MATLAB will find it and you will probably not even note it if you start Simulink or the MATLAB Coder.
BTW, MATLAB always had required those compilers. Only the Java runtime is shipped with it since R2013-something because they had a major issue with the Java update back then and the tech support went nuts =P
I'm interested in hooking up AMPL with Matlab to obtain objective values, gradients, and Jacobians to test ideas for optimization algorithms on a wide set of problems. I'm aware that I can use amplfunc.mex or spamfunc.mex to do this; however, I'm having trouble compiling the .mex files using the old netlib files on Windows. The link also given in a previous question:
Using MATLAB with AMPL
is outdated. Does anyone know where I can obtain these .mex files or offer any alternative solutions? Thanks in advance.
The mex files amplfunc.c and spamfunc.c are still available at http://www.ampl.com/netlib/ampl/solvers/examples. We aren't aware of a reason why these wouldn't compile, but if you are having trouble you could write to the AMPL user forum, ampl#googlegroups.com. Be sure to explain which function you are using and to give the complete text of any error messages you see.
As you may know, extrinsic functions are not outputted during the code generation process. Are there alternatives to these functions and/or solutions to this problem? My code generation error report is shown below :
Code Generation Error Report
I am surprised that I can't output size and rgb2gray either. Since these are essential to my program, I cannot avoid them.
Help will be much appreciated!
This is a good question, and I see similar questions fairly frequently. As I started using MATLAB Coder, one of the biggest pitfalls was the constant search for supported functions. I sympathize with your frustration, and I have a few tips, having been through this.
First, to your direct question, while imread isn't supported by Coder, size and rgb2gray are. Probably Coder is complaining about these because they have been passed mxArrays from the call to imread, which is fine when it is extrinsic, but not ok for separate generation. That's just a guess. A very useful tool in writing code is the list of Coder supported functions: List of Functions supported in MATLAB Coder
But even with those two, to replace imread is not a tiny task. You'll have to find another library that supports the particular file you're working with, and then stitch that in using coder.ceval. Alternatively, if you can find a pure MATLAB implementation of it, that might help.
Are you targeting a pure C library or a MEX file? If you intend to use this code within the MATLAB environment, you can always use imread separately and then pass the data.
And now to some more general observations: MATLAB Coder isn't a perfect MATLAB to C translation system. It's extremely powerful, and I've been able to write some very large projects with it, but if what you want is the ability to run any MATLAB code without MATLAB around, you should look at MATLAB Compiler, a different add-on. There's a very good Q and A about this here: MATLAB Compiler vs MATLAB Coder
When writing projects in MATLAB Coder, it's really best to start from scratch, knowing you're targeting C code ultimately. There are so many gotchas in the conversion from MATLAB to C that you have to be always vigilant while writing the MATLAB code.
One tool that helps is to right-click on a file in the "Current Folder" list that usually resides on the left-side of the main window, and select "Check Code Generation Readiness." You'll get a great report of potential problems in the file. I recommend using this often.
Another useful tool is to always put the %#codegen tag into your code. This alerts the MATLAB editor that the .m file is intended for code generation, so it provides extra context-sensitive information while you're writing the file. This helps enormously.
The most commonly missing functions for code generation are file IO functions. There are some good reasons for this, but it's frustrating nonetheless.
When you stitch in external C code, you use the coder.ceval function, which can provide excellent access to external libraries. Using this well is a whole other topic, outside the scope of this question.
If you can indicate exactly what kind of files you're interested in reading (PNG, BMP, TIFF, etc.) perhaps someone may be able to identify a good external library for you to use.
I have built an standalone Matlab application. I was expecting it to be faster than running the application from the Matlab environent but it is indeed a bit slower (1.3 seg per iteration vs 1.5 seg per iteration)
I am not counting the init time required by MCR but the execution of my code.
Is that the expected performance or should I be obtaining a performance improvement?
I haven't found any settings on the deployment tool that could help to reduce execution time.
Thanks in advance
Applications built with MATLAB Compiler should execute at pretty much exactly the same speed as within MATLAB.
MATLAB Compiler does not convert your MATLAB code into machine code in the same way as a C compiler does for C. What it does is to archive and encrypt your MATLAB code (note, it properly encrypts it, not just pcodes it as a comment suggests), create a thin executable wrapper and package them together, possibly also with MATLAB Compiler Runtime (MCR). MCR is very similar to MATLAB itself, without a graphical user interface, and is freely redistibutable.
When you run the executable, it dearchives and decrypts your MATLAB code and runs it against the MCR. It should run exactly the same, both in terms of results and speed.
Very old versions of MATLAB Compiler (pre-version 4.0) worked in a different way, converting a subset of the MATLAB language into C code, and compiling this. This provided a potentially significant speed-up, but only a subset of the language was supported and results, unless you were careful, could sometimes be different. Similar functionality is now available in the separate MATLAB Coder product.
There are a few small things you can do to improve performance: for example, within deploytool you can specify which toolboxes your application uses. deploytool uses a dependency checker to package up all MATLAB functionality that it thinks your code might possibly depend on, but it can't always tell exactly, as the functions your code needs might change at runtime. It therefore errs on the side of caution and includes more than necessary. By specifying only the toolboxes you know to be necessary, you can speed things up a little (it also speeds up the build process quite a bit).