My goal is to mex come c code which uses the library FFTW.
#include <matrix.h>
#include <mex.h>
#include "C:\Users\my_user_name\Documents\fftw-3.3.5-dll64\fftw3.h"
void mexFunction ( int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
int i, j, bw, bw2_1, size, size2_1, nrow, ncol;
int data_is_real;
int cutoff;
int rank, howmany_rank;
double *rresult, *iresult, *rdata, *idata;
double *workspace, *weights;
fftw_plan dctPlan;
fftw_plan fftPlan;
fftw_iodim dims[1], howmany_dims[1];
bw = 2;
weights = (double *)malloc(sizeof(double) * 4 * bw);
rdata = (double *)malloc(sizeof(double) * 5 * bw);
dctPlan = fftw_plan_r2r_1d(2 * bw, weights, rdata, FFTW_REDFT10, FFTW_ESTIMATE);
}
I'm currently using minGW and not Visual C++. If (from Matlab) I call
>>mex -c -LC:\Users\my_user_name\Documents\fftw-3.3.5-dll64 demo_fftw.c
it compiles correctly, but running
>> mex -LC:\Users\my_user_name\Documents\fftw-3.3.5-dll64 demo_fftw.c
Building with 'MinGW64 Compiler (C)'.
Error using mex C:\Users\MPUTHA~1\AppData\Local\Temp\mex_200676192178726_4216\demo_fftw.obj:demo_fftw.c:(.text+0x40):undefined reference to `__imp_fftw_plan_r2r_1d'collect2.exe: error: ld returned 1 exit status
I think that the error is because although fftw_plan_r2r_1d is declared in fftw3.h, it is defined somewhere else where the linker can't find it. I know that if I'm using Visual C++, then the .lib files contain the definitions, but the the README only tells you to compile the lib's if you are using Visual C++, and says nothing about using mingw.
What's the equivalent of a .lib file for mingw? Do I still need .lib's? If so, how do I compile them?
I apologize if this question is a duplicate, but I've looked around a bit and find lots of advice that works if you are using visual C++, but none concerning mingw.
You already made it possible for the compiler to see the FFTW include header file.
Now, you need to link with the actual FFTW code.
Fortunately, FFTW creators are merciful for Windows users and provided pre-built distros available here: http://www.fftw.org/install/windows.html
We have created precompiled DLL files for FFTW 3.3.5 in single/double/long-double precision, along with the associated test programs. We hope that these are sufficient for most users, so that you need not worry about compiling FFTW
These DLLs were created by us, cross-compiled from GNU/Linux using MinGW; the 64-bit version is possible thanks to the mingw-w64 project. You should be able to call them from any compiler.
So MinGW is fine. In your case I would do (untested):
mex -LC:\Users\my_user_name\Documents\fftw-3.3.5-dll64 demo_fftw.c libfftw3-3.dll
Related
Context
On Windows, using mingw32 and its x86_64 version. In order to use a third-party library (within Unity), I'am trying to build a wrapper library (dll) around the native one (to simplify the integration in Unity). I need this library to be 64bits.
The problem arises when linking against the created wrapper library in a test program: the program crash on a segfault, whereas the 32bits version runs just fine.
Procedure
I am using the 32 and 64bits version of the dll provided by the third-party (see Dependencies analysis on Picture) to compile wrapping libraries.
The wrapper library is simply wrapping some functions of the native library. The header is:
#include <stdlib.h>
#include <stdio.h>
#include "ATC3DG.h"
#pragma once
#ifdef __cplusplus
extern "C"
{
#endif
__declspec(dllexport) int trakSTAR_Init();
__declspec(dllexport) int trakSTAR_GetMeasurement(double S1_X[3], double S1_A[3], double *S1_T, unsigned short * S1_Q, double S2_X[3], double S2_A[3], double *S2_T, unsigned short * S2_Q, double S3_X[3], double S3_A[3], double *S3_T, unsigned short * S3_Q);
__declspec(dllexport) int trakSTAR_Close();
__declspec(dllexport) void trakSTAR_ErrorName(int errorcode, char *errortxt);
#ifdef __cplusplus
}
#endif
It is compiling fine for both the 32 and 64bits versions respectively with:
mingw32-gcc.exe -shared -Iinclude -o bin\Release\libWrapper.dll WrapperLib.c lib\win32\nativelib.lib
and
x86_64-w64-mingw32-gcc.exe -shared -Iinclude -o bin\Release\libWrapper64.dll WrapperLib.c lib\win64\nativelib64.lib
Then, compiling test codes linking this Wrapper dll using respectively:
mingw32-gcc.exe -I.\include -L.\test -llibWrapper .\test\MainTest.c -o test\Test32
and
x86_64-w64-mingw32-gcc.exe -g -I.\include -L.\test .\test\MainTest.c -o test\Test64 -llibWrapper64
also works fine and produce the two executables.
Problem
Now, while the 32bits version (Test32.exe) runs fine, the 64bits version produce a Segfault straight ahead (no even first console print). The necessary dll (native and wrapper for both 32 and 64bits version are in the execution folder).
When inspecting the two Wrapper dlls with Dependencies, I can't see any major difference (see picture).
What could be the cause of the problem with the 64bits library?
What are my options to understand what is going wrong and debug/inspect further?
Note: Compiling a test code against the native dll works fine for both in 32 and 64 bits.
Note2: Running GDB on the faulty test program does not provide more information.
I am developing firmware for stm32f4xx based systems.
For that I setup a toolchain based on the arm-none-eabi-gcc toolchain form ARM and cmake.
This toolchain works on Ubuntu. I can x-compile and debug(via openocd + eclipse IDE).
Now I like to add do some functional testing for my code. I was checking and it seems that cmocka is a good tool to use for embedded software testing.
I am now looking for an example/template that integrates a test into the cmake build.
let's assume a simple function at myfunc.c
#include "myFunc.h"
int buffer[10];
void myFunc(int i, int val) {
buffer[i] = val;
}
if I got it right I can do a test in a separate c file like "test.c"
#include "myFunc.h"
#include <cmocka.h>
// function success
static void test_myFunc_positive() {
for(int i = 0; i < 10; i++) {
myFunc(i,i);
}
}
static void test_myFunc_outofbounds() {
myFunc(100,44);
}
int main(void) {
const struct CMUnitTest tests[] = {
cmocka_unit_test(test_myFunc_positive),
cmocka_unit_test(test_myFunc_outofbounds),
};
return cmocka_run_group_tests(tests, NULL, NULL);
}
Usually I run
cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE="cmake/STM32Toolchain.cmake"
My question contains some sub questions:
1.) I installed libcmocka-dev. This is for my host system. Do I need to install cmocka for my arm-none-eabi-gcc compiler?
2.) How to setup cmake to pick the cmocka lib, build the test and run it on the host system? Think my toolchain file needs to be ignored.
Your source code looks pretty fine. Here is a recipe of how you could use cmocka.
I recommend to crosscompile cmocka's source code, too. In fact I doing it in this way:
Add cmocka.c to your sources
Add 'cmocka.h and cmocka_pbc.h and cmocka_private.h to your include directories.
Compile and run your software
PS: I don't know libcmocka-dev. I think this is a precompiled version of cmocka?
PPS: I had some trouble on getting cmocka's output redirected to my serial UART. If you're having the same problems, feel free to ask.
I finished working on my Checkers game engine and about to make it CheckerBoard (http://www.fierz.ch/cbdeveloper.php) compatible, and it states that.
CheckerBoard expects your engine to be compiled as a dll and to be in
the working directory of checkerboard.exe - or in the path. An engine
must support 2 required functions. ..., you must provide 2 more
functions for multi-version support. The calling convention for all
functions is __stdcall().
Required Functions
The current CheckerBoard API (version 2) requires the following 2
functions:
int WINAPI getmove(int board[8][8], int color, double maxtime, char str[1024], int *playnow, int info, int moreinfo, struct CBmove *move);
int WINAPI enginecommand(char command[256], char reply[1024]);
my engine includes the two above functions, i've got everything setup (the code) but i'm having troubles compiling it as dll, heres what i tried (using gcc)
gcc -c engine.c
gcc -shared -o engine.dll engine.o
it creates the dll as expected but the dll doesn't export any of the functions (as expected).
I used the Dependency walker program to scan the engine.dll file, and it shows that the dll exports the functions
_getmove#28
_enginecommand#20
i scanned one of the engines in the CheckerBoard directory and i found that they export the following functions:
getmove
enginecommand
i cant figure out why the dll i created exports differently, maybe its got
something to do with the WINAPI ?.
Any ideas ?
here's what it looks like
#define EXPORT __declspec(dllexport)
EXPORT int WINAPI getmove(int b[8][8], int color, double time, char str[1024], int *playnow, int info, int unused, struct CBmove *cbmove){
// ....
return 0;
}
EXPORT int WINAPI enginecommand (char str[256], char reply[1024]){
// ...
return 0;
}
i need both functions to be exported through the dll.
You probably need to annotate (the declaration of) these exported functions with Windows function attributes like __attribute__((dllexport)); I recommend having a declaration like
extern WINAPI getmove(int b[8][8], int color, double time,
char str[1024], int *playnow, int info,
int unused, struct CBmove *cbmove)
__attribute__((dllexport));
before that function's definition.
You may need to compile your source as position independent code (on Linux it is nearly required with -fPIC, for Windows DLL you need to check your documentation).
So try to compile with gcc -Wall -O -g -fPIC -shared engine.c -o engine.dll
See also this related question (and answers there).
PS. I never used Windows (only Unix since 1987 and Linux since 1993). I recommend reading Levine's Linkers and loaders book
I have problem linking the fftw library using cmake. I use a findFFTW.cmake file in order to find the library. I know this is successfully finding the library because I set the REQUIRED flag to be true for finding the library and the make process goes through fine.
Despite linking it with my executable, I am still getting undefined reference errors. Some related posts, whose solutions I have tried.
Undefined reference to "function name from external library"
http://answers.ros.org/question/171326/catkin-linking-order-undefined-reference-to-symbol/
Updates
Thanks to ComicSansMS, the CMake below should now model the dependencies correctly.
CMake file of project (updated 3/7)
cmake_minimum_required(VERSION 2.8.3)
project(gist_extractor)
## Find catkin macros and libraries
find_package(catkin REQUIRED COMPONENTS
roscpp
rospy
std_msgs
image_transport
cv_bridge
sensor_msgs
cmake_modules
)
find_package(OpenCV REQUIRED)
find_package(Eigen REQUIRED)
find_package(FFTW REQUIRED)
###########
## Build ##
###########
## Set GIST variables for building library
set(GIST_PATH /home/andy/Development/lear_gist-1.2)
## Specify additional locations of header files
include_directories(include ${catkin_INCLUDE_DIRS} ${GIST_PATH} ${FFTW_INCLUDES})
## Declare a gist library
add_library(gist SHARED ${GIST_PATH}/standalone_image.c ${GIST_PATH}/gist.c) # THIS IS NOT BEING BUILT
target_link_libraries(gist ${FFTW_LIBRARIES})
## Add cmake target dependencies of the library
#MESSAGE( STATUS "GIST_LIBRARY_PATH: " ${GIST_PATH})
## Declare a C++ executable
add_executable(gist_extractor src/gist_extractor.cpp)
target_link_libraries(gist_extractor ${catkin_LIBRARIES} gist)
EDITS 2
We now have a linking error if we use the above CMake file. Specifically the make process fails when I try running
target_link_libraries(gist_extractor ${catkin_LIBRARIES} gist)
I have a couple of observations. Firstly, my gist library is being built correctly based on the below console messages.
Linking C shared library /home/andy/Projects/ROS/robot_ws/devel/lib/libgist.so
[ 80%] Built target gist
Scanning dependencies of target gist_extractor
[100%] Building CXX object
`gist_extractor/CMakeFiles/gist_extractor.dir/src/gist_extractor.cpp.o
But we can see that there are undefined reference errors when we try to link our executable with the gist library.
Linking CXX executable gist_extractor
: undefined reference to `color_gist_scaletab'
Here's why I don't understand why this is occurring. In gist_extractor.cpp, I have included the header file that includes the 'color_gist_scaletab' function. Specifically, this 'color_gist_scaletab is in defined in 'gist.h' and implemented in 'gist.c'. I would think that building my library gist should give me access to 'color_gist_scaletab'. I have posted the relevant files below.
gist.h
#ifndef GIST_H_INCLUDED
#define GIST_H_INCLUDED
#include "standalone_image.h"
/*! Graylevel GIST for various scales. Based on Torralba's Matlab
* implementation. http://people.csail.mit.edu/torralba/code/spatialenvelope/
*
* Descriptor size is w*w*sum(n_orientations[i],i=0..n_scale-1)
*
* #param src Source image
* #param w Number of bins in x and y axis
*/
float *bw_gist_scaletab(image_t *src, int nblocks, int n_scale, const int *n_orientations);
/*! #brief implementation of grayscale GIST descriptor.
* Descriptor size is w*w*(a+b+c)
*
* #param src Source image
* #param w Number of bins in x and y axis
*/
float *bw_gist(image_t *scr, int nblocks, int a, int b, int c);
/*! #brief implementation of color GIST descriptor.
*
* #param src Source image
* #param w Number of bins in x and y axis
*/
float *color_gist(color_image_t *src, int nblocks, int a, int b, int c);
/*! Color GIST for various scales. Based on Torralba's Matlab
* implementation. http://people.csail.mit.edu/torralba/code/spatialenvelope/ */
float *color_gist_scaletab(color_image_t *src, int nblocks, int n_scale, const int *n_orientations);
#endif
gist_extractor.cpp
// color_gist_scaletab is defined in gist.h
// I'm including relevant header file
#include "/home/andy/Development/lear_gist-1.2/gist.h"
//SOME MORE STUFF
// This is where I call the function
float *gist_descriptor = color_gist_scaletab(im, nblocks, n_scale, orientations_per_scale);
It seems you did not model your dependencies correctly.
You use fftw from inside gist.c, which is part of the gist library target.
However, that target does not have a dependency to fftw, only the downstream target gist_extractor has. This is a recipe for trouble, especially in static builds, where toolchains are often picky about the order in which libraries appear on the linker command line.
Add fftw as a dependency to gist:
target_link_libraries(gist ${FFTW_LIBRARIES})
Also, there is no need to do this:
add_dependencies(gist_extractor gist)
target_link_libraries(gist_extractor ${GIST_PATH}/libleargist.a)
If both targets are built as part of the same project, simply do:
target_link_libraries(gist_extractor gist)
By using the target name instead of hardcoding the output file, you not only make your build script more portable, but also allow CMake to better track the inter-target dependencies for you.
I'm sort of a newbie to C coding but I've written a Matlab program for simulating neural networks and I wish to translate it to C code because our supercomputer cluster won't allow running more than a few Matlab simulations at once. To that end, I've found GotoBLAS to take care of the matrix math.
Unfortunately I'm not sure how to use it as I don't have a lot of experience in C and using external libraries. I'm assuming that 'dgemm' is a function in GotoBLAS from reading the BLAS guide pdf. I've been able to successfully compile GotoBLAS, but when I do:
gcc -o outputprog main.c -Wall -L -lgoto2.a
I get the messages:
undefined reference to 'dgemm'
As I understand it, I should be including some .h file (or maybe not) from GotoBLAS but I'm not sure which one (or if this is right at all).
Any help with this would be appreciated. Let me know if more information is needed.
One problem could be that the -L option expects a 'directory' name after it, and therefore gcc (or the linker invoked by gcc) is treating -lgoto2.a as a directory. The compiler does not complain about non-existent directories; it simply ignores them. Which directory did you expect to find the library in? (For the purposes of this answer, I'll assume it is in /usr/local/lib.)
Another problem could be that the library is not called libgoto2.a.a or libgoto2.a.so or something similar. You would not normally specify the .a suffix. (For the purposes of this answer, I'll assume that the library is either libgoto2.a or libgoto2.so.)
It appears that you don't need to specify where the headers are found; that means they're in a sufficiently conventional location that the compiler looks there anyway. If that's correct, the library too may be in a sufficiently conventional location too, and the -L option may be unnecessary.
So, you might be able to use:
gcc -Wall -o outputprog main.c -lgoto2
Or you might need to use:
gcc -Wall -o outputprog main.c -L/usr/local/lib -lgoto2
After some extensive discussion in the comments, and the information that the library is in the current directory and named libgoto2.a and that the symbol dgemm is still missing, I downloaded GotoBLAS2 version 1.13 and tried to compile it on a semi-supported platform (MacOS X, probably pretending to be Linux, with x86_64 architecture). The build was not completely successful - problems in some assembler code. However, poking around at the headers, there is one that looks like giving the solution to your problems:
cblas.h
In this, amongst many other function definitions, we find:
void cblas_dgemm(enum CBLAS_ORDER Order, enum CBLAS_TRANSPOSE TransA,
enum CBLAS_TRANSPOSE TransB, blasint M, blasint N, blasint K,
double alpha, double *A, blasint lda, double *B, blasint ldb,
double beta, double *C, blasint ldc);
All the function symbols in the header are prefixed with cblas_. Your code should be using:
#include "cblas.h"
You should be calling the functions using the Fortran name (in lower case) prefixed with cblas_:
cblas_dgemm(...);
And the correct link line to use is the first option listed above:
gcc -Wall -o outputprog main.c -lgoto2
At a pinch, you could define macros to map the regular (unprefixed) names to the correct C function names, but I'm not convinced it is worth it:
#define DGEMM cblas_dgemm
or (safer, because it checks the length of the argument list, but more verbose):
#define DGEMM(a,b,c,d,e,f,g,h,i,j,k,l,m,n) cblas_dgemm(a,b,c,d,e,f,g,h,i,j,k,l,m,n)
You can then write:
DGEMM(a, ..., n);
and the correct function would be called.
Experimentation with the partially successful build of GotoBLAS2 mentioned above shows that:
cblas.h is not self-contained (contrary to good coding standards).
common.h must be included before it.
common.h includes a lot of other headers:
config.h
common_x86_64.h
param.h
common_param.h
common_interface.h
common_macro.h
common_s.h
common_d.h
common_q.h
common_c.h
common_z.h
common_x.h
common_level1.h
common_level2.h
common_level3.h
common_lapack.h
The following code stands a chance of linking with a complete library:
#include "common.h"
#include "cblas.h"
void check_dgemm(void)
{
double A[33] = { 0.0 };
double B[33] = { 0.0 };
double C[33] = { 0.0 };
cblas_dgemm(CblasRowMajor, CblasNoTrans, CblasNoTrans,
3, 3, 3, 2.0, A, 3, B, 3, 3.0, C, 3);
}
int main(void)
{
check_dgemm();
return 0;
}
(In my admittedly broken build of the library, the complaints went from being 'cblas_dgemm() not found' to a number of other functions missing. This is a vast improvement!)
Ok I was able to find the answer on the GotoBLAS mailing list https://lists.tacc.utexas.edu/mailman/listinfo/gotoblas (which is not listed on the website as far as I can see). Here's a quick step by step on using GotoBLAS2 with C and GCC compiler.
Build GotoBLAS2 libraries (.so and .a), there's good documentation on that included with the libraries so I won't post it here. Include BOTH of these files in the libs directory of your choice as set by -L. I was only including one because I thought they were just different versions of the same library which was not correct.
Also link to -lgfortran as well if you wish to compile with gcc. -lpthread might also be useful, although I'm not sure, I've seen examples with it but it compiles without. Your gcc should look something like this:
gcc -Wall -o outprog -L./GotoLIBSDIR -lgoto2 -lgfortran -lpthread(maybe) main.c
Finally, call function_() instead of function(), so for example, dgemm_() when using gfortran to compile the fortran interfaces.
Alternatively to the fortran interface the cblas interface can be used as cblas_dgemm(). You still need to link to -lgfortran for this as otherwise linking to libgoto2.so will fail, and you need to link to that file to be able to use cblas_dgemm() correctly.
There doesn't appear to be any need to include any of the .h files or anything else.
Hopefully someone else will find this useful. Thanks for all the help!