tags:

views:

40

answers:

1

I'm working on a program that uses the Accelerate framework (for LAPACK) and I have several issues. The code is written in C but needs to include C++ headers. I renamed the file to .cpp but it caused two errors, shown below.

C++ Error Image

So I then realized tried to #include <Accelerate/Accelerate.h> to include the headers, since what our LAPACK coder did was retype the definitions (dgemm_(), dposv_(), etc.) at the beginning of the file and rely on the compiler/linker to work things out. So I commented out those and just did the #include. What came out was this:

Accelerate Error Image

So, how do I use the LAPACK functions using Accelerate in a C++ file? I'm not that familiar with LAPACK, so I'm not sure how that framework normally works.

+2  A: 

You should use call dgemm_ and dposv_ using the type __CLPK_integer or long instead of int. The error is because a long* cannot be implicitly converted to an int* in C++.

typedef long int    __CLPK_integer;
typedef long int    __CLPK_logical;
typedef float       __CLPK_real;
typedef double      __CLPK_doublereal;
typedef __CLPK_logical  (*__CLPK_L_fp)();
typedef long int    __CLPK_ftnlen;
KennyTM
Thanks, that helped a lot. Now I just have this error: `error: 'dgemm_' was not declared in this scope`. Interesting that it's fine with dposv_ which is called a few lines earlier in the same block of code.
jfm429
@jfm: Probably because there's no `dgemm_` in clapack. There is `cblas_dgemm` though.
KennyTM
That helps, but now: http://cl.ly/2Rc9/ EDIT: why can't you use Markdown in the comment fields? :\
jfm429
Actually, I think I've figured out a way to do the #include files in a way that will avoid issues and allow me to just use a C file for the LAPACK code; that way we won't have to deal with subtle differences in two versions of LAPACK, which it seems is what's causing this. Unless there's a way to somehow use the same code for both C and C++ versions of LAPACK...
jfm429
@jfm: `cblas_dgemm` has an entirely different prototype than `dgemm_`.
KennyTM
Yeah, that's the problem. :D I think we'll just end up using the workaround for the #include files. It seems to be working now, it's just a bit more awkward than I'd like (splitting some stuff into 2 files when it should be in 1) but I #included the second one in the first and it simplifies things for the rest of the #include statements. Thanks for your help, though. If we ever do decide to port things over those typedefs will help a lot.
jfm429