I have a matlab guide program I want to compile (package).
This program is not using the curve fitting toolbox.
Nevertheless the compiler complains about a missing licence.
mcc -C -o ...
Compiler version: 5.0 (R2013b)
Dependency analysis by DEPFUN.
Processing C:\Program Files\MATLAB\R2013b\toolbox\matlab\win64\mcc.enc
Processing C:\Program Files\MATLAB\R2013b\toolbox\curvefit\win64\mcc.enc
Depfun error: 'License checkout failed.
License Manager Error -4
Maximum number of users for Curve_Fitting_Toolbox reached.
How can I remove this dependancy for compilation?
According to the mcc document,
-N Clear Path
Passing -N effectively clears the path of all folders except the following core folders
(this list is subject to change over time):
matlabroot\toolbox\matlab
matlabroot\toolbox\local
matlabroot\toolbox\compiler\deploy
It also retains all subfolders of the above list that appear on the MATLAB path at compile time.
Including -N on the command line lets you replace folders from the original path,
while retaining the relative ordering of the included folders.
All subfolders of the included folders that appear on the original path are also included.
In addition, the -N option retains all folders that you included on the path that are not under matlabroot\toolbox.
In other words, you can clear all folders from the path and only keep the core MATLAB ones.
If you want to include some toolbox folders, you can use the -a option:
mcc ... -a C:\Program Files\MATLAB\R2013b\toolbox\...\...
Personally, I simply temporarily rename toolbox folders I don't need.
Just manually navigate to "matlabroot()\toolbox\" and rename, say, "signal" -> "signal_".
Surprisingly, the same could be done from the script, calling mcc() - almost no files in those folders are locked by matlab.exe.
This method doesn't sound like a "solution", of course it's just a "quick-and-dirty workaround". But, for me, it seem to work (R2015a).
Note, that you can easily check, what's actually included in your "deployed" dll (or exe), with 7z. Including files, added from toolboxes - see "my.dll.text\toolbox\"
PS1:
From my experience ,"-N" removes some unrelated stuff. Not all.
Moreover, when using "-N", you should carefully add stuff you need with "-I".
PS2:
In ".prj" file, created by deploytool(), there's something, that sounds related:
<matlab>
<root>D:\Program Files\MATLAB\MATLAB Production Server\R2015a</root>
<toolboxes>
<toolbox name="matlabcoder" />
...
</toolboxes>
...
</matlab>
but I've not checked, whether this actually controls witch toolboxes are used by mcc.
Related
I am running CoqIDE to use read the textbook series "Software Foundations", I am currently reading the volume "Logical Foundations". I just started Chapter 2 (Induction), but when I try to run the line
From LF Require Import Basics.
I get an error statement
The file ...\LF\Basics.vo contains library
Basics and not library LF.Basics
I tried renaming the directory the file was located in, and recompiled the buffers, but neither of these actions helped. What Shoudl i do in order to solve this problem?
We've been improving the explanation in the soon-to-be-released new version of LF. Here is the relevant bit:
For the [Require Export] to work, Coq needs to be able to
find a compiled version of [Basics.v], called [Basics.vo], in a directory
associated with the prefix [LF]. This file is analogous to the [.class]
files compiled from [.java] source files and the [.o] files compiled from
[.c] files.
First create a file named [_CoqProject] containing the following line
(if you obtained the whole volume "Logical Foundations" as a single
archive, a [_CoqProject] should already exist and you can skip this step):
[-Q . LF]
This maps the current directory ("[.]", which contains [Basics.v],
[Induction.v], etc.) to the prefix (or "logical directory") "[LF]".
PG and CoqIDE read [_CoqProject] automatically, so they know to where to
look for the file [Basics.vo] corresponding to the library [LF.Basics].
Once [_CoqProject] is thus created, there are various ways to build
[Basics.vo]:
- In Proof General: The compilation can be made to happen automatically
when you submit the [Require] line above to PG, by setting the emacs
variable [coq-compile-before-require] to [t].
- In CoqIDE: Open [Basics.v]; then, in the "Compile" menu, click
on "Compile Buffer".
- From the command line: Generate a [Makefile] using the [coq_makefile]
utility, that comes installed with Coq (if you obtained the whole
volume as a single archive, a [Makefile] should already exist
and you can skip this step):
[coq_makefile -f _CoqProject *.v -o Makefile]
Note: You should rerun that command whenever you add or remove Coq files
to the directory.
Then you can compile [Basics.v] by running [make] with the corresponding
[.vo] file as a target:
[make Basics.vo]
All files in the directory can be compiled by giving no arguments:
[make]
Under the hood, [make] uses the Coq compiler, [coqc]. You can also
run [coqc] directly:
[coqc -Q . LF Basics.v]
But [make] also calculates dependencies between source files to compile
them in the right order, so [make] should generally be prefered over
explicit [coqc].
If you have trouble (e.g., if you get complaints about missing
identifiers later in the file), it may be because the "load path"
for Coq is not set up correctly. The [Print LoadPath.] command
may be helpful in sorting out such issues.
In particular, if you see a message like
[Compiled library Foo makes inconsistent assumptions over
library Bar]
check whether you have multiple installations of Coq on your machine.
It may be that commands (like [coqc]) that you execute in a terminal
window are getting a different version of Coq than commands executed by
Proof General or CoqIDE.
- Another common reason is that the library [Bar] was modified and
recompiled without also recompiling [Foo] which depends on it. Recompile
[Foo], or everything if too many files are affected. (Using the third
solution above: [make clean; make].)
One more tip for CoqIDE users: If you see messages like [Error:
Unable to locate library Basics], a likely reason is
inconsistencies between compiling things _within CoqIDE_ vs _using
[coqc] from the command line_. This typically happens when there
are two incompatible versions of [coqc] installed on your
system (one associated with CoqIDE, and one associated with [coqc]
from the terminal). The workaround for this situation is
compiling using CoqIDE only (i.e. choosing "make" from the menu),
and avoiding using [coqc] directly at all. *)
I have a software that has multiple GUIs. To organize things better (or at least that was my thought), I have created several folders within the root directory as it can be seen in this image.
Within the folders i have both files with different formats and also some Matlab scripts.
When creating the Matlab executable using the Application compiler, and after selecting the main file, Matlab does not directly detected that these same folders are important for the code to run. Therefore I decided to add the folders manually.
Once the setup is created and installed, by running the application within the Matlab environment, I was able to debug one possible issue why the software is not running.
As you can see in the first image, the "play.png" is within the Images folder.
My question is pretty straight forward: how to force the Matlab Compiler to learn that all these folders are to be included in the setup? Not only to be included but their paths'
Two things could be going on:
You are not including the files in the package.
Make sure that you include them using the -a option of mcc:
mcc -m hello.m -a ./testdir/*
You can also use the GUI, of course, see here.
You are looking for the included files in the wrong place. Use ctfroot as the root of all paths in your code:
img_file_name = fullfile(ctfroot,'Images','brain.jpg'));
Check the unpacked CTF file (it is automatically unpacked when executed) to see the directory structure in it. ctfroot points to the root of the unpacked CTF file.
PS: This blog post might give you some more pointers.
I'm using mcc to compile my MATLAB project. The machine I'm using has many MATLAB toolboxes installed on it, but my code only requires a few (such as distcomp and images). However, whenever I run mcc, it ends up "processing" the mcc.enc files for many toolboxes, including those that my code does not need.
Here is the beginning of the output from mcc (I'm running it with -R '-nodisplay' to be compatible with the cluster I'm using).
Warning: No display specified. You will not be able to display graphics on the screen.
Compiler version: 4.15 (R2011a)
Processing /cm/shared/apps/matlab/7.12.0/toolbox/matlab/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/distcomp/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/images/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/stats/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/shared/imageslib/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/shared/system/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/shared/spcuilib/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/control/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/shared/controllib/engine/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/shared/controllib/general/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/signal/mcc.enc
Processing /cm/shared/apps/matlab/7.12.0/toolbox/nnet/mcc.enc
I've noticed it does the same thing when running mcc on my desktop as well. Some of these mcc.enc files (especially .../signal/mcc.enc and .../nnet/mcc.enc), take more time to process than it takes the rest of mcc to execute. Is there any way to exclude processing unneeded mcc.enc files?
Using the "deplyment tool" in the MATLAB IDE, go the project settings and from the "toolboxes on path" tab, unselect all toolboxes you do not need.
Also, there is an mcc argument -N that clears all folders from the path and only keep the core MATLAB ones.
-N Clear Path
Passing -N effectively clears the path of all folders except the
following core folders (this list is subject to change over time):
matlabroot/toolbox/matlab
matlabroot/toolbox/local
matlabroot/toolbox/compiler/deploy
It also retains all subfolders of the above list that appear on the
MATLAB path at compile time. Including -N on the command line allows
you to replace folders from the original path, while retaining the
relative ordering of the included folders. All subfolders of the
included folders that appear on the original path are also included.
In addition, the -N option retains all folders that the user has
included on the path that are not under matlabroot/toolbox.
I would recommend using the «fdep» function from the Matlab Central File Exchange:
http://www.mathworks.com/matlabcentral/fileexchange/17291-fdep--a-pedestrian-function-dependencies-finder
This function, applied to the main function of your program will tell you the toolboxes you are using and all the functions that are being used (recursively, so all the elemental functions are listed and you shouldn't miss any function). It is really useful to reduce the size and the compiling time of your final exe.
I'm trying to compile C shared library from Matlab. My Matlab code uses a lot of the image processing functionality. So, compiling goes fine, but when I call the dll from my application, I get messages like:
"Undefined function or method 'XYZ' for input arguments of type double".
I have verified my arguments are ok -- it's not a type problem. So, I tried adding %#function XYZ to my .m file, but that didn't help anything. Then, I tried using the -a flag in my compile command:
eval(['mcc -v -N -W lib:cshared -d ' clibdir ' -T link:lib -a edge' allFiles]);
but it fails to compile with:
Depfun error: 'Unable to locate edge as a function on the MATLAB path'
I have verified the image processing files are on my computer (I can run everything from matlab with no problem) and my path points to the directory that contains them.
I've also tried copying the toolbox .m files into my working directory, but that quickly balloons into a lot of files. And, for some functions, there is no .m - just a .mex - and i haven't found a way to include a mex file into my .dll.
What am I missing?
Have you tried including the Image Processing Toolbox folder using the -a option? For example:
mcc ... -a C:\Program Files\MATLAB\R2009a\toolbox\images\images
According to the mcc documentation, all files in this folder, as well as all files in any subfolders, are added to the CTF archive, and the folder subtree is preserved in the CTF archive.
If you don't want to include every subfolder, you can load only the files in a folder using a wildcard pattern:
mcc ... -a C:\Program Files\MATLAB\R2009a\toolbox\images\images\*
This may be necessary if there is a subfolder that may have functions or scripts that could shadow ones in the parent folder. For example, there is an edge.m function in the parent folder C:\Program Files\MATLAB\R2009a\toolbox\images\images\, and there is a ja subfolder that contains Japanese language help files (on Windows), one of which is also called edge.m. You wouldn't want this subfolder to be added when compiling, so you could either:
Remove that subfolder temporarily, add the parent folder without the wildcard option (to add the other subfolders you do want), then put that folder back.
Add the parent folder with the wildcard option (to add just the files), then separately add only the subfolders you want (such as #strel and private) with an additional -a command. NOTE: I'm uncertain if adding subfolders separately will maintain the folder subtree of the parent directory in the CTF archive in the same way as option #1 would!
If you don't want to include a large list of files that may not end up being used, you could instead try using the function DEPFUN to first get a list of dependencies for your MATLAB code. Then from this list you can find the specific Image Processing Toolbox functions your code uses and include only those when compiling. Since you specifically asked, this newsgroup thread mentions how to include a .mex file:
mcc ... -a imreconstructmex.mexw32 %# For a 32-bit Windows mex file
NOTE: There is also a MathWorks bug report I came across (which you need a login to see) that mentions a problem compiling applications using some Image Processing Toolbox functions on Windows in R2009b. There is a workaround given at the above link. This bug is fixed as of R2010a.
How do I build Borland C++ project files (bpr) and package files (bpk) from the command line? Project groups (bpg) are apparently make files and can be compile with make. But bpks and bprs are xml based and the Export to Makefile won't compile with make.
If I put a project in a bpg, make can't seem to find any of the files specified in the bpg since they all appear to be relative references. I changed the references to absolutes and make reports:
Fatal: Unable to open makefile
You don't need to directly compile a bpr. Just create a bpk which just includes that single bpr, and you can use make to compile it.
"c:\program files\borland\cbuilder5\bin\make" -B -s -fabc.bpg
If you also have other borland compilers installed, do not call the make.exe from the other compiler.
EDIT: execute the make command in the directory where the bpg and bpr is located.
Using bpr2mak and make works for me just fine, so as Roger said, you need to give details on what errors you're getting. BPK files can also be processed with bpr2mak. I'm using this method to compile a large project with many components, without difficulties.
Perhaps you could give some more information on 'won't compile'.
I.e. What error messages are you getting.
One frequent problem the come up with make is addressed at the following
http://www.delphigroups.info/3/8/36427.html