Boost logo

Ublas :

Subject: Re: [ublas] Bindings: second C linkage of overloaded function 'cbdsqr_'
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2011-04-11 16:05:58

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 <>, but the versions from the mingw distributable or from <> 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.