Cannot link dll to mexfunction in Matlab cmex function - matlab

Does anyone have idea about how to link dll or lib in the Mex command?
I have a C code link a external function from GHXDLL.dll and GHXDLL.lib. I defined the external function in header that the same one i used to generate the dll and lib.
typedef struct GHX{
double output[28];
int val;
}GHX;
#ifdef __cplusplus
extern "C" { // only need to export C interface if
// used by C++ source code
#endif
#ifdef GHXDLL_EXPORTS
#define MATHFUNCSDLL_API __declspec(dllexport)
#else
#define MATHFUNCSDLL_API __declspec(dllimport)
#endif
MATHFUNCSDLL_API void GHXfunction(double *XIN, double *parameter, int mode, int hour, GHX *result);
#ifdef __cplusplus
}
#endif
I wrote a test code to call this function with linking to the lib and dll, and it works. Meanwhile, I wrote a simple test code for the Mex API, then I compile it from command line by
mex test.c,
and it works.
Then, I met problem. When I add the external function to the Mex API and compile in matlab with the following command, it fails.
mex -largeArrayDims -I'c:\Users\zzhang\API' -L'c:\Users\zzhang\API' -lGHXDLL GHXCmexAPI.c
The errors are:
Error using mex
Creating library GHXCmexAPI.lib and object GHXCmexAPI.exp
GHXCmexAPI.obj : error LNK2019: unresolved external symbol __imp_GHXfunction referenced in function mexFunction
GHXCmexAPI.mexw64 : fatal error LNK1120: 1 unresolved externals
I know this error means the mexfunction did not link to the lib with external function, but i have tried many different ways, and still cannot deal with it.
I hope someone can help me figure out how to mex it.
Thanks.
Zhicheng

List the DLL import library file by name rather than via -l. Also add -v and inspect the link.exe command line:
mex -v -largeArrayDims -I'c:\Users\zzhang\API' -L'c:\Users\zzhang\API' ...
GHXCmexAPI.c GHXDLL.lib
When inspecting the link command, also verify that there is a /LIBPATH: with the folder containing your DLL.

Related

Compiler generates FPU instructions

I realize a CMSIS Project solution with VS Code but I've an error on an include file :
#include "stm32f10x.h"
And I've got this error :
In included file: "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"clang(pp_hash_error)
core_cm3.h(90, 6): Error occurred here
The path of this file is here :
C:\Users\"name"\AppData\Local\Arm\Packs\Keil\STM32F1xx_DFP\2.4.0\Device\Include
But I think I forgot something during the configuration.
I justa want to build my C file but VS code doesn't make the link between my .h and my CMSIS project.
You are never supposed to #include "stm32f10x.h"
You only #include "stm32f1xx.h" and it will include the other headers you need.
You must also define a macro on the command line, one of STM32F101x6, STM32F101xB, STM32F101xE or STM32F101xG.
For most compilers you can define this with an argument like -DSTM32F101xB.
After that you will need particular command line arguments that match your chosen processor, such as -mthumb -mcpu=cortex-m3 -mfpu=none.
Maybe your error was specifying an incorrect -mfpu=.

Runtime linker error using Thrust in MATLAB MEX file

I'm having trouble using the CUDA Thrust library in MATLAB MEX code.
I have an example that runs fine externally, but if I compile and run it as a MEX file, it produces "missing symbol" errors at runtime.
It seems specific to the Thrust library. If instead of thrust::device_vector I use cudaMalloc with cudaMemcpy or cublasSetVector then everything is fine.
Minimum example
thrustDemo.cu:
#ifdef MATLAB_MEX_FILE
#include "mex.h"
#include "gpu/mxGPUArray.h"
#endif
#include <thrust/device_vector.h>
#include <vector>
void thrustDemo() {
std::vector<double> foo(65536, 3.14);
thrust::device_vector<double> device_foo(foo);
}
#ifdef MATLAB_MEX_FILE
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, mxArray const *prhs[]) {
thrustDemo();
}
#else
int main(void) { thrustDemo(); }
#endif
The problem
I can compile this from the command line (nvcc thrustDemo.cu) and run the resulting executable just fine.
When I try to build this as a MATLAB MEX file (mexcuda thrustDemo.cu from within MATLAB R2017a), it compiles and links just fine:
>> mexcuda thrustDemo.cu
Building with 'nvcc'.
MEX completed successfully.
But when I try to run it, I get the following error:
>> thrustDemo()
Invalid MEX-file '/home/kqs/thrustDemo.mexa64':
Missing symbol '_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5c_strEv' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5emptyEv' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt12length_errorC1EPKc' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt13runtime_errorC2EPKc' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEPKc' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1ERKS4_' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1Ev' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEpLEPKc' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEpLERKS4_' required by '/home/kqs/thrustDemo.mexa64'.
This is pretty foreign to me; can somebody tell me what this means? These look like linker errors, but they're being generated at runtime. Also, I thought Thrust was a template library, so what is there to link to?
And finally, replacing thrust::device_vector with cudaMalloc and either cudaMemcpy or cublasSetVector works just fine. So for now I'm stuck with a bunch of cudaMalloc in my code, which seems...distasteful. I'd really like to be able to use Thrust.
Versions
MATLAB R2017a
nvcc V8.0.61, gcc 5.4.0, Ubuntu 16.04.2
NVidia driver 375.39, GTX 1060 graphics card (Compute Capability 6.1)
Update: ldd output
Per comments, I checked the dependencies of the MEX file using ldd thrustDemo.mexa64:
linux-vdso.so.1 => (0x00007ffdd35ea000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f097eccf000)
libcudart.so.8.0 => /usr/local/cuda-8.0/targets/x86_64-linux/lib/libcudart.so.8.0 (0x00007f097ea69000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f097e852000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f097e489000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f097e180000)
/lib64/ld-linux-x86-64.so.2 (0x0000562df178c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f097df7b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f097dd5e000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f097db56000)
I tried looking for one of these missing symbols, and was able to find it:
$ nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep "_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5c_strEv"
0000000000120be0 W _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5c_strEv
So it seems that MATLAB must be looking in the wrong place.
It turns out this has nothing to do with Thrust but is rather an issue with MATLAB having its own version of the C++ standard libraries.
Thanks to #Navan and #talonmies for their helpful comments.
Interpreting the error
First, MATLAB is raising these errors when it's loading the MEX file. The MEX file has external dependencies, and MATLAB could not find them.
After checking these dependencies with the Linux utility ldd, then using nm to list the symbols define by these libraries, I found that the system version of the libstdc++ shared library actually contains these "missing symbols". Hence why the externally-compiled version works just fine.
Solving the issue
The root problem, then, is that MATLAB ships with its own, older version of libstdc++ that is lacking these functions. Knowing the root cause, I found questions like these:
How to tell mex to link with the libstdc++.so.6 in /usr/lib instead of the one in the MATLAB directory?
Version GLIBCXX_3.4.11 not found (required by buildW.mexglx)
which describe workarounds that were indeed successful for my problem.
In particular, I used LD_PRELOAD when launching MATLAB to force MATLAB to use the system libstdc++ instead of its own copy:
$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/local/MATLAB/R2017a/bin/matlab
Update: a better solution
It turns out that the folks at GCC are well aware of this incompatibility and discuss it here:
In the GCC 5.1 release libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list. These changes were necessary to conform to the 2011 C++ standard which forbids Copy-On-Write strings and requires lists to keep track of their size.
In order to maintain backwards compatibility for existing code linked to libstdc++ the library's soname has not changed and the old implementations are still supported in parallel with the new ones.
...
The _GLIBCXX_USE_CXX11_ABI macro (see Macros) controls whether the declarations in the library headers use the old or new ABI.
To tell gcc to use the older ABI, we just need to define _GLIBCXX_USE_CXX11_ABI as 0 before we include any library headers, e.g. by passing a -D option to the compiler:
-D_GLIBCXX_USE_CXX11_ABI=0
For the sake of completeness, I'll mention that my full mexcuda call looks like this:
nvcc_opts = [...
'-gencode=arch=compute_30,code=sm_30 ' ...
'-gencode=arch=compute_50,code=sm_50 ' ...
'-gencode=arch=compute_60,code=sm_60 ' ...
'-std=c++11 ' ...
'-D_GLIBCXX_USE_CXX11_ABI=0 ' % MATLAB's libstdc++ uses old library ABI
];
mexcuda_opts = {
'-lcublas' % Link to cuBLAS
'-lmwlapack' % Link to LAPACK
'-lcufft' % Link to cuFFT
['NVCCFLAGS="' nvcc_opts '"']
'-L/usr/local/cuda/lib64' % Location of CUDA libraries
};
mexcuda(mexcuda_opts{:}, src_file);

mex file compiled without errors but not working in matlab

First I wanted to compile MatConvNet library for using in windows form this tutorial
(Compiling MatConvNet on Windows)
but I couldn't. Then I think it is better to compile a very simple file and after that going to compile the library.
I have Matlab R2013a 64 bit and Visual Studio 2010 64 bit.
my program Test.cpp
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[],int nrhs, const mxArray *prhs[])
{
printf("Hello! :)\n");
}
I can compile Test.cpp in matlab with mex Test.cpp
And when I type test output is Hello! :)
I also can set the correct configuration according to tutorials below and compile it without errors.
1) http://coachk.cs.ucf.edu/GPGPU/Compiling_a_MEX_file_with_Visual_Studio2.htm
2) http://www.orangeowlsolutions.com/archives/490
But when I run it in Matlab, nothing happen. There is no output and Matlab doesn't give me any error.
What is the problem?
Notice that:
in (1) second step is adding "mexversion.rc" from "matlab\extern\include" to the project But this file dose not exist in my computer so I couldn't do it.
In Visual Studio I needed to add tow headers in below for compiling the program.
include "stdafx.h"
include "maxrix.h"
so the Test.cpp in Visual Studio is:
#include "mex.h"
#include "stdafx.h"
#include "matrix.h"
void mexFunction(int nlhs, mxArray *plhs[],int nrhs, const mxArray *prhs[])
{
printf("Hello! :)\n");
}
Pre-compiled header shenanigans
A problem with the Visual Studio version of the code is the pre-compiled header file stdafx.h causing the compiler to ignore any code above it (the mex.h include):
#include "mex.h"
#include "stdafx.h" // ANYTHING above here is IGNORED!
#include "matrix.h"
Move the stdafx.h include to the top or turn off PCH in projects settings and remove the include.
printf vs. mexPrintf
Before getting into MEX project setup, note that printf points to mexPrintf courtesy of mex.h:
#define printf mexPrintf
So, using printf is not an issue, but probably not good practice. The problem comes if you redefine printf after including mex.h or fail to get this define on account of the PCH header.
Regarding MEX in Visual Studio
I posted a more formal guide to setting up a Visual Studio projects for building MEX files as an answer to the more commonly-reference question on this topic, and I would also suggest here to use Visual Studio property sheets to get your project set up to build a MEX file. The details are in the referenced post, but you just need to:
Set the MATLAB_ROOT environment variable.
Create a new DLL project.
Under Property Manager (from View menu), right click on each project's build configuration and "Add Existing Property Sheet...", choosing the MATLABx64.props file from this GitHub repo.
printf only works in native C. You need to use mexPrintf. Therefore, your code should be this:
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[],int nrhs, const mxArray *prhs[])
{
mexPrintf("Hello! :)\n");
}
In general, printing to standard output in a MEX script doesn't appear in the MATLAB command prompt. If you want to display messages in MATLAB, you need to use mexPrintf instead of printf.
To be explicit, if you consult the mexPrintf documentation, a caveat can be seen towards the end:
In a C MEX-file, you must call mexPrintf instead of printf to display a string.
BTW, I recommend this awesome MEX tutorial here: http://classes.soe.ucsc.edu/ee264/Fall11/cmex.pdf. This is the tutorial that I used to get started with programming MEX wrappers in MATLAB. You'll also see that the first example is of the same "Hello World" caliber that you are trying to get running :)
Good luck!
How To Compile a C/CPP File and Create mex File for Using in Matlab
I found the solution by #rayryeng help and (How to build mex file directly in Visual Studio?) #jorre's post.
This is tested with Matlab R2013a 64 bit and Visual Studio 2010 64 bit.
Test.cpp
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[],int nrhs, const mxArray *prhs[])
{
mexPrintf("Hello World123! :)\n");
}
1.Create a new project in VS -> Visual C++ -> General -> Empty Project.
The name of your Project will be the name of mex file.
You can change it later.
2.Change the Debug to Release.
Right click on the project -> Properties -> Configuration properties -> General
Set Target Extension to .mexw64
Set Configuration Type to Dynamic Library (.dll)
Configureation poperties -> VC++ Directories:
5.Add $(MATLAB_ROOT)\extern\include; to Include Directories
Configuration properties -> Linker -> General:
Add $(MATLAB_ROOT)\extern\lib\win64\microsoft; to Additional Library Directories
Configuration properties -> Linker -> Input:
Add these things to Additional Dependencies
libmx.lib
libmex.lib
libmat.lib
Configuration properties -> Linker -> Command Line:
Add /export:mexFunction to Additional Options
Now you must set you platform to x64 otherwise you'll get error like"Error 1 error LNK2001: unresolved external symbol _mexPrintf".
9.Configuration Properties -> Configuration Manager -> Active Solution Platform -> New -> x64 -> Copy Settings From Win32
Now you can compile your file and get mex file.
If you see these tutorials there are other things thar are not needed and may cause problems.
(http://coachk.cs.ucf.edu/GPGPU/Compiling_a_MEX_file_with_Visual_Studio2.htm)
Create an empty Project, not a MFC Dll Project.
There is no need to *.def file.
There is no need to add "mexversion.rc" into your project.
There is no need to add "MATLAB_MEX_FILE" as a preprocessor definition.

Linking and LOADING static .lib with mex

So, I have a MEX gateway script file that calls my C source code. I've used the -L and -I commands to link my 64-bit compiled GSL libraries (.libs) to my mex executable, which is then compiled under the extension of .mexw64.
I want for this executable to be transferred to another windows machine and run fine, without any GSL libraries installed. That is the the only solution, I don't care what he arguments are regarding the benefits of the dynamic linking/code generation upon compile-time are. I want an executable that has every function not only (of course) pre-declared, but also PRE-DEFINED.
I was lead to believe that this is what 'static' linking is vs. dynamic; but I've read some contradictory definitions all around the interwebs. I need a completely 100% standalone, singular file.
Supposedly you can link the actual .obj file in the mex function, which I can generate, but unfortunately I then get unresolved symbol errors.
Someone else mentioned that I can use the -l (lowercase L) to directly link the actual .lib(s) needed, statically, but that is NOT true.
So is there anyone that can lead me in the right direction, either how to have everything not only linked but to also have the DEFINITIONS linked and ready to load when executable is run--completely standalone, or why I am running into unresolved symbols/linker errors when I include my .obj file? Am I misunderstanding something elementary about the linking process?
Also: To elaborate a bit more, I have the GSL libraries built and linked via Visual Studio for the 64 bit architecture, and I can link it easily with MATLAB, so that is not my problem (any more).
EDIT: I've seen the post here:
Generating standalone MEX file with GNU compilers, including libraries
This doesn't solve my problem, however, although it is the same question. I don't have access to gcc; it's finally compiling on the MSVS12 compiler in MATLAB, I'm not going try to recompile using GCC via MinGW (already tried, couldn't figure it out), so -static and .a options are out.
In your previous post, you mentioned that you decided to compile GSL library with Visual C++, using the VS solution provided by Brian Gladman.
Here is a step-by-step illustration on how to build a MEX-function that links against GSL libraries statically:
Download GNU GSL sources (GSL v1.16)
Download the matching Visual Studio project files (VS2012 for GSL v1.16)
Extract the GSL tarball, say to C:\gsl-1.16
Extract the VS project files on top of the sources, this will overwrite three files as well as add a folder C:\gsl-1.16\build.vc11.
Open Visual Studio 2012, and load the solution: C:\gsl-1.16\build.vc11\gsl.lib.sln
Change the configuration to the desired output: for me I chose platform=x64 and mode=Release
First you must build the gslhdrs project first
Now build the whole solution. This will create two static libraries cblas.lib and gsl.lib stored in C:\gsl-1.16\lib\x64\Release (along with corresponding PDB debugging symbols). It will also create a directory containing the final header files: C:\gsl-1.16\gsl
Next we proceed to build a MEX-function. Take the following simple program (computes some value from a Bessel function, and return it as output):
gsl_test.c
#include "mex.h"
#include <gsl/gsl_sf_bessel.h>
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
if (nrhs != 0 || nlhs > 1) mexErrMsgTxt("Wrong number of args.");
plhs[0] = mxCreateDoubleScalar(gsl_sf_bessel_J0(5.0));
}
This is how to compile the above C code in MATLAB:
>> mex -largeArrayDims gsl_test.c -I"C:\gsl-1.16" -L"C:\gsl-1.16\lib\x64\Release" cblas.lib gsl.lib
Finally we test the MEX-file, and compare it against the value reported by MATLAB's own Bessel function:
>> x = gsl_test()
ans =
-0.1776
>> y = besselj(0,5)
y =
-0.1776
>> max(x-y) % this should be less than eps
ans =
8.3267e-17
Note that the built MEX-function has no external DLL dependencies (other than "Visual C Runtime" which is expected, and the usual MATLAB libraries). You can verify that by using Dependency Walker if you want. So you can simply deploy the gsl_test.mexw64 file alone (assuming the users already have the corresponding VC++ runtime installed on their machines).

unresolved external symbol - Error using Matlab API

I'm trying to read a .mat-file in C++ with MSVS 2008 but when building a simple program I get the following error:
1>ex3.obj : error LNK2019: unresolved external symbol _matClose referenced in function _main
1>ex3.obj : error LNK2019: unresolved external symbol _matOpen referenced in function _main
I've researched Google as well and it seems that the compiler can't link to the libraries needed for using this functions (matOpen and matClose). I never used an external library before but I tried everything I found in Google to add the Matlab libraries. I did the following:
TOOLS --> Options --> Projects and Solutions --> VC++ Directories --> Show directories for: include files --> then I added the path of the matlab include directory --> C:\Program Files\MATLAB\extern\include
I did the same with the library files: C:\Program Files\MATLAB\extern\lib\win64\microsoft
I also did that for the project:
Right click on the project --> Properties --> Configuration Properties --> C/C++ --> General --> Additional Include Directories --> and added "C:\Program Files\MATLAB\extern\include\win64"
Then I did the same at Linker --> General --> Additional Library Directories --> and added "C:\Program Files\MATLAB\extern\lib\win64\microsoft"
So I really don't know where the problem is. Here is the source code I'm trying to build:
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <mat.h>
int main(int argc, char *argv[])
{
const char *file = "mozart_part1.mat";
MATFile *pmat;
pmat = matOpen(file, "r");
if(pmat == NULL)
{
std::cout << "Error: could not open MAT-file!";
return(1);
}
matClose(pmat);
}
Can you see or guess any mistakes I made
Take a look here.
Go through the steps.
What I think you've missed is step 7:
7.Locate the .lib files for the compiler you are using under matlabroot\extern\lib\win32\microsoft or matlabroot\extern\lib\win64\microsoft. Under Linker Input properties, add libmx.lib, libmex.lib, and libmat.lib as additional dependencies.
Edit:
Both Matlab and Visual C++ should be either 32bit or 64bit. There are two options:
Find these 3 lib files from another Matlab which is 32bit. Direct your linker there instead.
Make your Visual C++ 64bit. See here how it's done.
Solution:
What eventually worked was option 2, using this link with instructions.
I solved the Problem!
#Michael Litvin: you were right! I didn't know that you have to switch MSVS 2008 to x64 platform.
As the Matlab libraries are provided as x64 binaries you have to switch your MSVS compiler to x64 as well. I followed these steps to do that: http://software.intel.com/en-us/articles/configuring-microsoft-visual-studio-for-64-bit-applications/
Thanks for you help!