I need generate Dll file from matlab cods and use this in C++. I can not couple dll file in c++. Please help me.
This looks promising: How do I create a C - shared library with MATLAB Compiler 3.0 which can be used in other projects?
In short:
Compile your MATLAB files into a DLL (on Windows): mcc -t -L C -W lib:mylib -T link:lib -h <MATLAB files> libmmfile.mlib
Add mylib.lib to your MSVC (or your own IDE) project
Make sure to call the initialization and termination routines from your
code before calling any of the MATLAB files that are compiled. You need to call: mylibInitialize();
Afterwards, you should call the termination routine: mylibTerminate();
All of the symbols in mylib.dll will also appear in mylib.h.
You can call the functions compiled from the MATLAB code by invoking mlfFoo(...), from your C code.
Related
I am trying to use the MinGW-w64 Compiler in Matlab. I have it installed and Matlab recognizes the compiler. My question is 2-fold:
1) I cannot get it to compile all the .c code into a header. I typed
mex -output HTKToolsFolder *.c
Building with 'MinGW64 Compiler (C)'.
And got
Error using mex
C:\Users\username\Documents\MATLAB\MatlabHTK\htk\HTKTools\HBuild.c:39:46: fatal error: HShell.h: No such
file or directory
#include "HShell.h" /* HMM ToolKit Modules */
^
compilation terminated.
I'm not sure what the .h extension is. That file is located in another folder but if I tell Matlab to compile .h files it doesn't recognize the file extension
mex -output hfilescompiled *.h
Error using mex
Unknown file extension '.h'.
If it helps, HShell.h is called by some of the .c files
The second question is, once question #1 is answered, can I apply this to a directory with many folders of C++ code? Or do I have to use the mex command for every single folder?
I've watched the Matlab tutorial: https://www.mathworks.com/solutions/matlab-and-c.html and I've also read the Matlab help files for mex and loadlibrary.
Any advice is greatly appreciated as this is the first time I've mixed C++ and Matlab. Thanks in advance!
You want to do this:
mex HBuild.c -IC:\Path\To\H\Files
where C:\Path\To\H\Files is whatever the directory is that contains HShell.h.
This will create a MEX-file called HBuild (assuming that HBuild.c contains a mexFunction function, and no other dependencies exist).
If you do mex *.c, then all C source files in that directory will be combined into a single MEX-file. I doubt that this is what you want. You need to call mex for each of the MEX-files you want to build. Each MEX-file will become a function available within MATLAB.
I received this error at bash interface while compiling my Fortran source code to read a netcdf file.
I used gfortran -o firstrd -I/use/local/include/ rdNetcdf.f90 -L/use/local/lib/ -libnetcdff.a but it returns
/use/bin/ld: cannot find -libnetcdff.a
I followed your previous recommend syntax on this issue before.
I saw libnetcdff.a in the directory /use/local/lib and not /use/lib directory.
nc-config is a tool that comes with the netcdf library that provides information on the library's configuration, including how to compile and link programs that use netcdf. nc-config --help describes the tool's usage. Its output includes the lines:
--fc Fortran compiler
--fflags flags needed to compile a Fortran program
--flibs libraries needed to link a Fortran program
In particular, run nc-config --fc --fflags --flibs on your system to find out how to compile and link Fortran programs that use netcdf.
I am trying to incorporate a C library into some Rcpp code.
I can use the C library in a C++ program easily. I 'make' the C library, which creates the .a and .dll files in the /lib folder. I can then use the package by including the header in the program and running something like this from command line:
cc myfile.cpp -o myfile -Ipath.to.header path.to.lib.a -lz
This essentially tells the compiler to take the .cpp program, include headers from -I, and to link to two libraries.
Getting this to work with Rcpp shouldn't be overly difficult if I understand makevars correctly (which I unfortunately don't seem to).
I add the library to a folder in my package, and in src I add a makevars and makevars.win that look like this:
PKG_CFLAGS=
# specify header location
PKG_CPPFLAGS=-Ipath.to.lib/include
# specify libs to link to
PKG_LIBS=path.to.lib/lib/file.a -lz
# make library
path.to.lib/lib/file.a:
cd path.to.lib;$(MAKE)
This correctly 'makes' the .a and .dll files for the library, however none of the Rcpp magic runs (i.e. in the build I never see the g++ system call that compiles the files in src), so "no Dll was created".
I am fairly certain this is a problem in my makevars target that makes the library. When I remove that portion from the makevars, and 'make' the library from the command line myself before building the package, I get the proper g++ calls with my -I and -l statements, but I get errors about undefined references.
I notice that the -l statements are only included in the final g++ call where the final .dll is made, but isn't included in the earlier g++ calls where the files with the library headers are compiled.
So I have two problems:
How do I fix my makevars so that it 'makes' the library, but doesn't stop Rcpp from compiling the files in src?
How do I deal with the undefined references? The library is clearly not header-only, so I am guessing it needs the -l statement in the earlier g++ calls, but that may not even be possible.
The best approach is to avoid complicated src/Makevars file altogether.
One easy-ish approach around this: use configure to build your static library, then once you actually build just refer to it in src/Makevars.
I use that scheme in Rblpapi (where we copy an externally supplied library in) and in nloptr where we download nlopt sources and build it 'when needed' (ie when no libnlopt is on the system).
What is the correct way to convert files like d3d11.lib that are provided in the DirectX SDK to the *.a GCC library format? I've tried the common reimp method for converting *.lib files to *.a files, but it doesn't seem to work.
Step one involves creating a definitions file:
bin\reimp -d d3d11.lib
Let's say I want to use the D3D11CreateDevice function that should be provided in this library. If I open the created definitions file everything seems to be OK:
LIBRARY "d3d11.dll"
EXPORTS
(...)
D3D11CreateDevice
D3D11CreateDeviceAndSwapChain
(...)
Next I try to create the *.a file using the definitions file and the original lib file:
bin\dlltool -v -d d3d11.def -l libd3d11.a
This does in fact produce a valid library (and no error messages when dlltool is set to verbose), but if I try to use the function D3D11CreateDevice that should be implemented in it, I get an error:
undefined reference to `D3D11CreateDevice'
If I ask nm what symbol are present in the library (and filter using grep), I get this:
D:\Tools\LIB2A>bin\nm libd3d11.a | grep D3D11CreateDevice
File STDIN:
00000000 I __imp__D3D11CreateDeviceAndSwapChain
00000000 T _D3D11CreateDeviceAndSwapChain
00000000 I __imp__D3D11CreateDevice
00000000 T _D3D11CreateDevice
The imp function is the function that calls the actual implementation of D3D11CreateDevice inside the DLL. However, that actual implementation is now prefixed by an underscore.
Why is "_D3D11CreateDevice" defined while "D3D11CreateDevice" is not even though it is mentioned in the definitions file?
Just do:
copy d3d11.lib libd3d11.a
Alternatively you use X:\path\to\d3d11.lib on the GCC command line instead of -ld3d11. The GNU utilities on Windows use the same PECOFF archive format that Microsoft's tools use.
An outdated version of dlltool will prepend an underscore to every function when converting d3d11lib. Solved it by using a dlltool.exe from MinGW-w64 4.9.2. This dlltool produces a library with the correct function names.
When using the regular d3d11.lib provided by Microsoft in combination with headers provided by anyone, a SIGSEGV will occur when stepping into the library at runtime. This means that you do have to convert to the *.a format for some reason not investigated.
Say, I have mylibrary.ml which provides wrappings to library.c and I want to bytecode-compile and provide mylibrary.ml as a library for other ocaml code. Compiling this to bytecode (and I am not considering compiling ocaml to native code here) produces a number of files, and I am wondering if there is any reason to keep them all? Or to provide them all to other users of the library?
I (so far) understand that I need the bytecode library object mylibrary.cma so that I can use mylibrary in the ocaml toplevel as
ocaml mylibrary.cma
or that I can
#load "mylibrary.cma";;
from an ocaml script. Then also the compiled interface mylibrary.cmi, and the dllmylibrary.so (which contains the C parts of the code) are needed for the above to work. And the non compiled interface definition file mylibrary.mli is nice to keep for documentation purposes.
But is there any reason to retain also the mylibrary.cmo file, if I have the mylibrary.cma file? In what kind of case would someone like to have that, too?
EDIT: I mean, I need to construct the .cmo in the makefile and then use that to construct the .cma, but I was thinking to remove .cmo after this, to keep the directory marginally cleaner.
So, apparently the purpose of different files are (when limiting this to bytecode compiler):
mylibrary.mli - human readable interface definition (not strictly needed, compiler only needs .cmi)
mylibrary.cmi - compiled interface, needed when compiling code calling mylibrary
library.o - C object file
dlllibrary.so - shared library object made of the .o
dlllibrary.a - static library object made of the .o
mylibrary.cmo - bytecode object compiled from mylibrary.ml
mylibrary.cma - bytecode library
Then, mylibrary.cma (with mylibrary.cmi and dlllibrary.so) are needed when loading mylibrary from the toplevel:
#load "mylibrary.cma";;
OR
One could compile a bytecode program that dynamically links with mylibrary.cma (mylibrary.cmi and dlllibrary.so also needed):
ocamlc mylibrary.cma <program>.ml
OR
dynamically linking with bytecode object, instead of the bytecode library (files needed: mylibrary.cmo, mylibrary.cmi, dlllibrary.so):
ocamlc dlllibrary.so mylibrary.cmo <program>.ml
(Note: then run the bytecode with: ocamlrun -I . <program>, assuming dlllibrary.so is in the current directory.)
OR
statically linking with objects (files needed: mylibrary.cmo, mylibrary.cmi liblibrary.a)
ocamlc -custom liblibrary.a mylibrary.cmo <program>.ml
OR
statically linking with library objects (files needed: mylibrary.cma, mylibrary.cmi, liblibrary.a)
ocamlc -custom -I . mylibrary.cma <program>.ml
So depending on how one is going to use the library in the future, different files are needed. Except .mli is only needed for human readers, and the object file.o compiled from the C library is not needed (but would be needed when compiling to native code in some cases).
You should even keep the source code of the library. Very often when upgrading the Ocaml compiler (e.g. from 3.12 to future 3.13), you previous *.cmo or *.cma files won't be able to work without recompilation.
Assuming you can always clean and recompile things (e.g. you have the two traditional targets clean and all to make) you can only keep the *.cma