|
|
Ublas : |
Subject: Re: [ublas] Bindings with ACML MSVC example project? I have linking problems.
From: George Slavov (gpslavov_at_[hidden])
Date: 2012-06-30 14:54:22
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_at_[hidden]
> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: gpslavov_at_[hidden]
>