Hello,
I have two libraries that uses LAPACK subroutines, but one of them uses Boost.NumericBindings and the other one uses LAPACKE (the official LAPACK C interface). I have troubles to make them work together since I got many conflict errors at compilation time. Here below is a stupid (but effective) example: --- [boost_lapacke.cpp] --- #include <boost/numeric/bindings/lapack/computational/getrf.hpp> #include <lapacke.h> int main() { } --- [/boost_lapacke.cpp] --- Now, try to compile it. For instance, in my case: $ g++ -Wall -Wextra -ansi -pedantic -I/usr/include/lapacke -I$HOME/sys/src/git/boost -I$HOME/sys/src/svn/boost-numeric_bindings -o boost_lapacke boost_lapacke.cpp -llapack -lblas -llapacke -lm The errors I get are like the one below: --- [error] --- In file included from boost_lapacke.cpp:2:0: /usr/include/lapacke/lapacke.h:11760:56: error: conflicting declaration of C function ‘void sgetrf_(int*, int*, float*, int*, int*, int*)’ lapack_int* ipiv, lapack_int *info ); ^ In file included from /home/.../sys/src/svn/boost-numeric_bindings/boost/numeric/bindings/lapack/detail/lapack_names.h:17:0, from /home/.../sys/src/svn/boost-numeric_bindings/boost/numeric/bindings/lapack/detail/lapack.h:17, from /home/.../sys/src/svn/boost-numeric_bindings/boost/numeric/bindings/lapack/computational/getrf.hpp:39, from boost_lapacke.cpp:1: /home/.../sys/src/svn/boost-numeric_bindings/boost/numeric/bindings/lapack/detail/lapack_names.h:326:36: note: previous declaration ‘void sgetrf_(const fortran_int_t*, const fortran_int_t*, float*, const fortran_int_t*, fortran_int_t*, fortran_int_t*)’ #define LAPACK_SGETRF FORTRAN_ID2( sgetrf, SGETRF ) ^ /home/.../sys/src/svn/boost-numeric_bindings/boost/numeric/bindings/detail/config/fortran.hpp:33:32: note: in definition of macro ‘FORTRAN_ID2’ #define FORTRAN_ID2( id, ID2 ) id##_ ^ /home/.../sys/src/svn/boost-numeric_bindings/boost/numeric/bindings/lapack/detail/lapack.h:940:6: note: in expansion of macro ‘LAPACK_SGETRF’ void LAPACK_SGETRF( const fortran_int_t* m, const fortran_int_t* n, float* a, ^ --- [/error] --- Any idea on how to solve these conflicts? My system is: - Linux Fedora 22 x86_64 - LAPACK 3.5.0 - Boost git version - Boost.NumericBindings svn version - GCC 5.1.1 Thank you very much. Best, Marco _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email] |
Hi Marco,
the prototypes from lapacke.h seem to lack const qualifiers. One option could be to extend the python script to create a lapacke.h with const qualifiers from a given lapacke.h. Another option would be to allow the python script to generate bindings which use a "given" lapacke.h, and generate appropriate const_cast<>s in the // Overloaded function for dispatching to // * netlib-compatible LAPACK backend (the default) A nicer variant of this option would be to have lapacke as another backend, and switch between the different backends via macros like BOOST_NUMERIC_BINDINGS_LAPACK_CLAPACK for switching from the // * netlib-compatible LAPACK backend (the default) to // * ATLAS's CLAPACK backend What would you prefer? A macro like BOOST_NUMERIC_BINDINGS_LAPACK_LAPACKE for switching to a lapacke backend, or some possibility to generate lapacke.h with const qualifiers, with the possible option to directly incorporate such an improved lapacke.h into future versions of lapacke? Regards, Thomas Klimpel _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email] |
On Thu, Sep 3, 2015 at 12:21 PM, Thomas Klimpel <[hidden email]> wrote:
> Hi Marco, > > > the prototypes from lapacke.h seem to lack const qualifiers. > > One option could be to extend the python script to create a lapacke.h with const qualifiers from a given lapacke.h. > > Another option would be to allow the python script to generate bindings which use a "given" lapacke.h, and generate appropriate const_cast<>s in the > // Overloaded function for dispatching to > // * netlib-compatible LAPACK backend (the default) > > A nicer variant of this option would be to have lapacke as another backend, and switch between the different backends via macros like BOOST_NUMERIC_BINDINGS_LAPACK_CLAPACK for switching from the > // * netlib-compatible LAPACK backend (the default) > to > // * ATLAS's CLAPACK backend > > What would you prefer? A macro like BOOST_NUMERIC_BINDINGS_LAPACK_LAPACKE for switching to a lapacke backend, or some possibility to generate lapacke.h with const qualifiers, with the possible option to directly incorporate such an improved lapacke.h into future versions of lapacke? > Hi Thomas, Thank you for the reply. My first "no-brain" answer would be: I choose the fastest option :) Instead, thinking a little bit more, I'm not sure but maybe the option that uses BOOST_NUMERIC_BINDINGS_LAPACK_LAPACKE is the most flexible, do you? By the way, I've tried to manually add the new backend by looking at what has been done for CLAPACK. After a "grep -ri CLAPACK" command, I've added these files: boost/numeric/bindings/lapack/detail/lapacke.h boost/numeric/bindings/lapack/detail/lapacke_options.hpp I've changed these files: boost/numeric/bindings/detail/config/fortran.hpp boost/numeric/bindings/lapack/driver/gesv.hpp boost/numeric/bindings/lapack/driver/posv.hpp boost/numeric/bindings/lapack/computational/trtri.hpp boost/numeric/bindings/lapack/computational/potri.hpp boost/numeric/bindings/lapack/computational/potrs.hpp boost/numeric/bindings/lapack/computational/getrs.hpp boost/numeric/bindings/lapack/computational/potrf.hpp boost/numeric/bindings/lapack/computational/getri.hpp boost/numeric/bindings/lapack/detail/lapacke_option.hpp But probably I've done it wrong as I still get errors about constness. Also, I get errors about complex arguments since NumericBindings uses void* while LAPACKE uses "by default" _Complex. I've quoted "by default" because the type can be changed via macro definition. So I've tried: * -Dlapack_complex_float="std::complex<float>" -Dlapack_complex_double="std::complex<double>" * -Dlapack_complex_float="void" -Dlapack_complex_double="void" Both of them fail to work. In particular the last one fails since LAPACKE declares variable of complex type thus resulting in an error (a void variable cannot be declared) If you are interested I can send you or share in some way the changed files. Cheers, Marco _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email] |
Free forum by Nabble | Edit this page |