For a while I have been compiling some mex files with own CUDA functions. I have the nvcc set up and everything compiles, and runs without problems.
However, when compiling
mex -largeArrayDims ./Source/Atb.cpp ./Source/voxel_backprojection.cu ./Source/voxel_backprojection2.cu -outdir ./Mex_files
I always get the following messages after the successful compilation
Building with 'NVIDIA CUDA Compiler'.
Could Not Find C:\CUDA_MATLABtests\MyToolbox\Mex_files\Atb.exp
Could Not Find C:\CUDA_MATLABtests\MyToolbox\Mex_files\Atb.exp
Why do I get this messages, If the code seems to work properly?
Should I have them? If so, should I manually create them? How?
In Visual Studio, an export (.exp) file is created so that others can link against your library.
For your typical mex file, no one will be linking against it, therefore the .exp files are not necessary. This is why your mex file runs just fine despite the fact that MATLAB issues this warning. Their uselessness in the context of mex files is further verified by the fact MATLAB tries to delete them itself during the cleanup process.
del PATH/Atb.pbj PATH/Atb.exp PATH/atb.manufest
Since Visual Studio generates these files by default (and there doesn't seem to be a good way to disable this behavior), I believe that they should exist somewhere on your machine after your code is compiled. It may actually be that MATLAB's mex configuration doesn't properly handle where to place these files and they end up somewhere other than your output directory.
I don't have Visual Studio currently, but you could probably search your local machine for that .exp file just to verify that it is indeed created and it's just placed somewhere that MATLAB isn't expecting. If this is the case, you can likely tweak your mexopts to handle this.
That being said, this warning is harmless for your typical mex file and can safely be ignored.
MATLAB Answers post on the topic
Related
I am trying to profile a CUDA code that is embedded in a mex file, called from MATLAB. Running on a win7 x64 machine, MATLAB r2014b
The code is structured as follows:
MATLAB test.m
->contains some standard code generating variables (and calling 1 or 2 minor own MATLAB fucntions)
-> calls testcuda.mex
->contains small, standard, no library C++ code
-> calls either test1.cu or test2.cu
->.cu files end in cudaDeviceReset();
I did the following, as stated in several places on the internet:
Compiled mex files. Test them. They work.
Add exit in the end of test.m.
Launch the NVIDIA Visual Profiler. File -> New Session.
add the full path of the Matlab executable file, for example C:\Program Files\MATLAB\R2014b\bin\matlab.exe
Working directory: add the full path of the Matlab .m file. C:\CUDA_MATLABtests\MyToolbox
Arguments: -nojvm -nosplash -r test
However, when I run the profiler,I get
======== Warning: No CUDA application was profiled, exiting
And nothing more.
I am missing some instruction?
Is there any particular code structure that would make the profiler not to profile?
A Matlab installation comes with two binaries, a launcher in <matlabroot>\bin and the main application in <matlabroot>\bin\<arch>. The later is the executable which also executes the mex functions in it's address space.
When a debugging tool needs to start the application directly, you have to start the one in <matlabroot>\bin\<arch>.
When a debugging tool automatically attaches to child processes as well, it is typically sufficient to start the binary in <matlabroot>\bin setting the -wait parameter. Seeing the launcher application terminating, debugging tools often stop.
Never use the binary in <matlabroot>\bin\<arch> directly unless you have to.
I created a .mex file of a MATLAB file test.m from MATLAB R2012b using MATLAB coder.
I got the output file test_mex.mexa64. I was hoping to use this .mex file in MATLAB 7.5.0 (R2007b) but it shows the following error.
Invalid MEX-file '/work/sreekanthl/test_mex.mexa64': libmwblascompat32.so:
cannot open shared object file: No such file or directory.
How can I make this .mex file work in 7.5.0 (R2007b)?
I agree with David Kelley's answer for general MEX files but there is a special consideration for MATLAB Coder generated MEX files. MATLAB Coder generated MEX code is expected to be forward compatible but generally is not expected to be backward compatible. In other words, you are expected to be able to use such MEX code in a newer release than the one with which it was generated, however using the code in an earlier release cannot be guaranteed to work.
The reason for this is that the MEX code uses various runtime libraries which ship with MATLAB. These libraries advance over time and the MEX file from the newer version may depend on features that the older libraries do not provide, or even on a new library which does not exist in the older release as you are seeing here.
If you want to create MEX code that is compatible with earlier releases, you could generate a standalone target such as a static library or a shared library (LIB or DLL respectively for MATLAB Coder), and either:
Try to use loadlibrary to call the generated code in MATLAB
Write a generic MEX interface for it and compile that MEX code in the older release
These options are more work but should enable you to create a MEX file or shared library usable in an older release.
While TMW says that mex functions are usually compatible between versions, it's not officially supported and quite common to run into issues with it.
The only reliable option is to simply recompile the generated source code that Matlab coder created (i.e., the C code) in the version you want to run it in using the mex function.
I encountered a very strange problem when using the SYSTEM function to call an executable file from Matlab.
First, I can run the executable file in a window console with no problem. However, when I call system(foo.exe) in Matlab, it does nothing but return the status value -1.0737e+09, and it does not throw any warnings or errors.
I am using Matlab R2009b on a 32-bit windows system and the executable file depends on OpenCV2.40.
The system path variable definitely include all the required lib directories. I also tried adding the relevant paths in the LD_LIBRARY_PATH, and copying the dlls in the working directory. These attempts do not change anything.
I also tried calling SYSTEM('cmd') from Matlab, and running the executable in the invoked window console. It gave me no response, either. It seems like the running environment of the console called from Matlab is different from the original window console.
Running the same code on a different machine in Matlab is successful.
I had this exact same problem. It turned out I simply needed to restart Matlab. I had not restarted Matlab after installing OpenCV2.1.
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 am trying to execute some example code from a MATLAB toolkit, 'oscmex'. This toolkit allows for communication using the OSC protocol over MATLAB. I presume this question is non-specific; it should apply to any toolkit that is set-up in the manner that this one is.
Reasons aside, I'm having some simple trouble getting the toolkit up and running. The toolkit comes with no documentation whatsoever; just a set of six DLL files (in one directory), and a set of four MATLAB '.m' example code files (in another directory). Every toolkit I've used in the past has either been a built-in kit or has had an intuitive (semi-automated) install procedure.
After downloading the toolkit, the first thing I tried was to simply run one of the '.M' example codes. This failed as the first line of the code contained the function osc(), which is not (currently) recognised by MATLAB.
So, I figured maybe I need to move the '.M' files into the same folder as the DLLs; perhaps MATLAB would see the functions inside the DLLs. No dice.
So, I realise that I have to somehow link MATLAB to the DLLs on startup. I tried adding the DLLs to a folder and adding an entry to that in the 'pathdef.m' file. This also failed.
I've read somewhere I can load a DLL file by using the loadlibrary() function. So, I tried doing this for the DLL files. This failed on the first file:
>> loadlibrary('osc_free_address.dll')
Error using loadlibrary>lFullPath (line 587)
Could not find file osc_free_address.h.
I'm starting to run out of options... How can I get this set of DLLs up and running?
Browsing this library's web page it would seems these DLLs are just old form of mex files.
Therefore, they should not be used in the context of shared library (e.g., using loadlibrary and calllib), but rather compiled directly to mex files.
To do so, I would suggest the following steps:
Make sure you have a working mex compiler configured for your Matlab.
In matlab, type:
>> mex -setup
this will guide you through the configuration process. I understand that you are working on a windows machine, I usually work with visual studio compiler - works best for me.
This library's README file suggests that OSC
requires liblo 0.22 or later. See http://plugin.org.uk/liblo/
Make sure you have this library and it is located in you LD_LIBRARY_PATH (see e.g., this question for details, or the mex docs).
Get the source code for OSC library from their repository.
Compile the sources in matlab using
>> mex -O -largeArrayDims osc_free_address.c
>> mex -O -largeArrayDims osc_free_server.c
and so on for all 7 c source files. After mex-ing the c files you'll have mex files that you can run from Matlab as if they were regular functions.
You may find it useful to use the library's make file, as suggested by Andrew Mao.
Good luck,
If you look at the build for that software, it is compiling mex files, not DLLs (shared libraries): http://sourceforge.net/p/oscmex/code/4/tree/trunk/src/osc_make.m.
I would try using the mex commands instead of the dll commands (perhaps the files are just misnamed.) Even better, I would compile the files yourself with mex using the build file in source.
Note that the instructions also say that you need liblo-0.22 in order to run the library, so make sure you have that accessible as well.
I took a look at your OSC Toolkit. It seems they have been compiled by MATLAB mex. But, it is not mentioned for which kind of architecture they have been built. You can type mexext at MATLAB command prompt to find the extension for your MATLAB mex files. Then, change the DLL extensions to the given extension. If the original mex is compatible with your matlab, the DLL can be easily accessed by MATLAB. Just make sure to add the folder to your MATLAB path.
Try changing the extension from .dll to .mexw32 (in win32), or .wexw64 (in win64). It's a long shot but it might work.
The Shared Libraries cannot be used directly. As you have mentioned, you need to load them into MATLAB using loadlibrary. According to the documentation, loadlibrary takes two arguments (at least). The first argument is the name of the file, and the second one is the header file which contains definition of functions and external variables. If you do not provide the header file, the MATLAB looks for the a file with the same name as the DLL. Having said that, you need to have access to the header file or at least if you know how the function looks like, you need to write a header for the DLL.
I have worked with the DLLs in MATLAB. The MATLAB is not very user-friendly as long as DLL is concerned. Especially, if the DLL is written in a language other than C (or C++) you will have trouble loading the function into MATLAB.
Besides, MATLAB can only support some specific DLLs. Based, on your version of MATLAB, you need to find out whether or not the shared library is supported by MATLAB. Have a look at Here
In a nutshell, it is not easy to load a DLL into MATLAB. You need to have some information from DLL.