|
|
Ublas : |
Subject: Re: [ublas] Bindings: second C linkage of overloaded function 'cbdsqr_'
From: George Slavov (gpslavov_at_[hidden])
Date: 2011-04-12 19:40:59
On 4/11/2011 4:05 PM, Thomas Klimpel wrote:
> George Slavov wrote:
>> I have been able to use gotoblas in a separate project that directly
>> called the functions defined in clapack.h. However, when I try to
>> include the lapack header (I just include it but I haven't written any
>> code to use it) from the ublas bindings, I get trouble. The error is
>> c:\documents and settings\username\my
>> documents\libs\clapack\clapack.h(512) : error C2733: second C linkage
>> of
>> overloaded function 'cbdsqr_' not allowed
>> c:\documents and settings\username\my
>> documents\libs\clapack\clapack.h(509) : see declaration of 'cbdsqr_'
>>
>> There are 100 more of these of these functions that the compiler
>> complains about, after which it gives up. Unfortunately, MSVC isn't
>> telling me where this other different C declaration is.
> The solution is real simple: don't include "c:\documents and settings\username\my documents\libs\clapack\clapack.h" and don't define BOOST_NUMERIC_BINDINGS_LAPACK_CLAPACK. The numeric_bindings library already includes a header with its own "const correct" prototype declarations for the functions declared in clapack.h:
>
> #include<boost/numeric/bindings/lapack/detail/lapack.h>
>
> But now you protest that you don't include "c:\documents and settings\username\my documents\libs\clapack\clapack.h" explicitly? That's quite possible, because some files from the numeric_bindings library (getrf.hpp, getri.hpp, getrs.hpp, potrf.hpp, potri.hpp, potrs.hpp, trtri.hpp, gesv.hpp, posv.hpp) will include<boost/numeric/bindings/lapack/detail/clapack.h> if you define BOOST_NUMERIC_BINDINGS_LAPACK_CLAPACK. This file contains the lines
>
> extern "C" {
> #include<clapack.h>
> }
>
> The<clapack.h> file which is expected here is not the one from CLAPACK, but the one from the ATLAS library. And BOOST_NUMERIC_BINDINGS_LAPACK_CLAPACK is also just referring to this part of the ATLAS library, and has nothing to do with the CLAPACK library (besides the name).
>
>
> I know why the compiler complains when the<clapack.h> from CLAPACK and<boost/numeric/bindings/lapack/detail/lapack.h> are included in the same translation unit. They both declare prototypes for c-functions with the same name, but the types in the prototypes are not identical ("void*" instead of "complex*" for example). This makes the compiler think that these are overloads, but overloads or not allowed for functions with C linkage.
>
>
>> I guess we aren't talking about the same thing, but I've got to tell
>> you... I'm not surprised. The landscape of BLAS is incredibly
>> frustrating and oftentimes I can't make head or tail of instructions.
>>
>> I was under the impression that using the Fortran libraries on Windows
>> is a major pain because of the unavailability of Fortran compilers for
>> Windows that are free and interoperate with Visual Studio well.
> I can understand how this impression arises, but it isn't actually true. The recent gcc Fortran compilers are actually pretty interoperable with Visual Studio. I tested with<http://www.equation.com/servlet/equation.cmd?fa=fortran>, but the versions from the mingw distributable or from<http://tdm-gcc.tdragon.net/> will probably work just as well.
>
> That said, it's actually a good idea to start with CLAPACK, and only try this stuff later when you are eager and confident to try some experiments.
>
>
>> If you have the patience for it, I would appreciate it if you could
>> explain to me what ATLAS and LAPACK really are in relation to gotoblas
>> because now I'm completely confused.
> - BLAS is a library for which there exists different tuned implementations. Examples are the reference Fortran implementation, gotoblas and ATLAS.
> - LAPACK is a Fortran library making use of whichever BLAS library you will link it with in order to achieve high performance.
> - CLAPACK is the f2c'ed version of this Fortran library, also making use of whichever BLAS library you will link it with...
> - Both LAPACK and CLAPACK also come with a relatively slow reference implementation of the BLAS library, so if you don't like the extra effort, there is no need to link against an optimized BLAS library.
> - gotoblas is an optimized BLAS library.
> - The ATLAS library also provides an optimized BLAS library. It also provides an implementation of the official c-interface to BLAS (which is called cblas), and has implemented a very small subset of the LAPACK routines directly with a c-interface, which it calls clapack. ATLAS can be built in a way that LAPACK and clapack can be used at the same time, when linking against LAPACK. The official c-interface to LAPACK has been developed much later by Intel MKL developers and seems to be called LAPACKE.
> - The Intel MKL library and the AMD AMCL library provide both BLAS and LAPACK library implementations.
>
>
> It's actually not as complicated as it sounds.
>
>
> Regards,
> Thomas
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: gpslavov_at_[hidden]
Thank you very much for this detailed reply! I really appreciate it. I
hope to pick up this problem in the next couple of days since I've had
to put it on hold for a bit.
Best,
George