Compilation error when using blaspp, lapackpp or slate together with boost

Issue #1 resolved
Jan Martin Brockmann
created an issue

Dear developers,

we run into some problems when using blasspp, lapackpp and/or slate together with boost. In case the BLAS/LAPACK/SLATE header is included before the boost header, compilation with gcc < gcc-8 fails. It is related to a known issue cf [1], including C99 complex.h in c++: For instance

#include "blas.hh"
#include<boost/random.hpp>
int main( )
{

}

can not be compiled with gcc < gcc8, e.g. it fails with gcc version 7.3.1. Simply changing the order of includes everything compiles

#include<boost/random.hpp>
#include "blas.hh"
int main( )
{

}

As discussed in [1], this results from explicitly including the C99 <complex.h>. Is complex.h really necessary in blas_config.h and lapack_config.h, or would as discussed in [1] including <ccomplex> be fine for blaspp and lapackpp? Including <ccomplex> instead of <complex.h> in blas_config.h makes the program compiling, but I am not aware if it affects blasspp somehow.

Best regards, Jan Martin

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

Comments (6)

  1. Mark Gates

    Thanks for pointing this out. Currently the solution is to define LAPACK_COMPLEX_CPP, which will configure LAPACK to use the C++ std::complex instead of the C _Complex.

    The long explaination: lapack_fortran.h and lapack_config.h will eventually be files in LAPACK proper, not in LAPACK++. They are essentially cleaned up subsets of lapack/LAPACKE/include/lapacke.h and lapacke_config.h. As lapacke.h is intended for C code, not C++ code, it must include complex.h when compiling as C. However, it would probably make sense when compiling as C++ to use std::complex by default instead of the C _Complex. We'll discuss that.

  2. Mark Gates

    On further examination, it turns out we don't need to include blas_config.h in the public blas.hh. We only need it when compiling the BLAS++ library. So the issue should be resolved now, no need to define anything.

  3. Jan Martin Brockmann reporter

    But Mark, if I see it correctly the definition of blas_int is now missing for lapackpp, blaspp compiles fine, but now lapackpp fails with unknown type blas_int... Or have I missed sth? The error somehow shows the typedef... I do not rally see what happens.

    make
    g++ -O2 -std=c++11 -MMD -Wall -pedantic -Wshadow -Wno-unused-local-typedefs -Wno-unused-function -fopenmp  -DFORTRAN_ADD_ -DADD_  -DHAVE_BLAS -DHAVE_CBLAS -DHAVE_LAPACK -DLAPACK_VERSION=30800 -DHAVE_LAPACKE -fPIC -I./include -I../blaspp/include -c src/upmtr.cc -o src/upmtr.o
    In file included from ./include/lapack_wrappers.hh:4:0,
                     from ./include/lapack.hh:4,
                     from src/upmtr.cc:1:
    ./include/lapack_util.hh:139:18: error: ISO C++ forbids declaration of ‘blas_int’ with no type [-fpermissive]
     typedef blas_int (*lapack_s_select2) ( float const* omega_real, float const* omega_imag );
                      ^
    ./include/lapack_util.hh:139:18: error: typedef ‘lapack::blas_int’ is initialized (use decltype instead)
    ./include/lapack_util.hh:139:20: error: ‘lapack_s_select2’ was not declared in this scope
     typedef blas_int (*lapack_s_select2) ( float const* omega_real, float const* omega_imag );
                        ^~~~~~~~~~~~~~~~
    ...
    

    If I add the blas_config.h include to blas.hh everything compiles fine.

    Best, Jan Martin

  4. Log in to comment