Thanks for your response Thomas. I really should have mentioned my build environment. I'm on Windows 7, 64-bit as you guessed, using MSVC 2010 and Acml 5.1.0. I was really hoping the integer 8 macro will do the trick, but it didn't seem to change anything. I really want to use 64-bit versions of things because I'll be using pretty large data sets, so I'm not sure I even want to get the 32-bit version of Acml working.
I traced the ublas bindings call I have
boost::numeric::bindings::blas::gemv(1.0f,A,x,0,blasResult);
all the way to the Acml call
BLAS_SGEMV( &blas_option< Trans >::value, &m, &n, &alpha, a, &lda, x,
&incx, &beta, y, &incy );
and my debugger shows the first parameter (blas_option< Trans >::value) contains 'N' as a char, so that looks right. But something here confuses me. Acml.h shows the signature of sgemv is
extern void sgemv(char transa, int m, int n, float alpha, float *a, int lda, float *x, int incx, float beta, float *y, int incy);
Note the first param is not a pointer to a char, but the char itself. So what's with all the reference operators in the ublas bindings code?
Best,
George
Any other thoughts on what else I can try?
On Sat, Jun 30, 2012 at 5:30 AM, Thomas Klimpel
<Thomas.Klimpel@synopsys.com> wrote:
George Slavov wrote:
> If no one can help me with that, I could describe the issue I'm having.
> My minimal test program involves calling gemv, really simple,
> but I get a linker error: unresolved external symbol sgemv_.
> I am positive that I'm linking to the right libs from ACML.
> I actually included all the libs I could find in the lib folder.
> I used dumpbin to show the symbols in libacml_mp.lib and
> I couldn't find sgemv with an underscore in the end so I decided to
>
> #define BIND_FORTRAN_LOWERCASE
>
I can confirm that I also need to define this for ACML + MSVC.
> But then I got a compilation error because ublas bindings define ilaenv which
> forwards to LAPACK_ILAENV which ends up being named the same.
> So the ublas binding function seems to be trying to call itself and it has the wrong signature for that.
I just tested this, and your analysis is probably correct. Here is what I did and the result:
C:\nobackup\numeric_bindings\libs\numeric\bindings\lapack\test>%BOOST_ROOT%\b2 numbind=acml-msvc include_test
Das System kann den angegebenen Pfad nicht finden.
...patience...
...patience...
...found 1190 targets...
...updating 2 targets...
compile-c-c++ ..\..\..\..\..\bin.v2\libs\numeric\bindings\lapack\test\include_test.test\msvc-9.0express\debug\numbind-acml-msvc\threading-multi\include_test.obj
include_test.cpp
C:\nobackup\numeric_bindings\boost/numeric/bindings/lapack/auxiliary/ilaenv.hpp(32) : error C2660: 'boost::numeric::bindings::lapack::ilaenv' : function does not take 9 arguments
call "C:\Programme\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo @"..\..\..\..\..\bin.v2\libs\numeric\bindings\lapack\test\include_test.test\msvc-9.0express\debug\numbind-acml-msvc\threading-multi\include_test.obj.rsp"
...failed compile-c-c++ ..\..\..\..\..\bin.v2\libs\numeric\bindings\lapack\test\include_test.test\msvc-9.0express\debug\numbind-acml-msvc\threading-multi\include_test.obj...
...failed updating 1 target...
...skipped 1 target...
> So then I decided to rename the ublas binding function just to see what happens (haha) and everything magically compiled and linked. But then at runtime I got
>
>
> *** ACML error: on entry to SGEMV parameter number 1 had an illegal value
>
>
> That's when I decided to give this a rest and ask for help. Any help would be appreciated!
I can't reproduce this one, but I tested only on a 32-bit windows-xp with MSVC-9.0 express edition (while writing this email). If you are on a 64-bit windows, it might help to
#define BIND_FORTRAN_INTEGER_8
(or link against the variant with 32-bit integers, which is probably also provided by ACML)
Regards,
Thomas
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: gpslavov@gmail.com