conversion from ‘int’ to non-scalar type ‘El::BigFloat’

[gidiko]

When configuring Elemental build (for use in conda recipes for libSkylark) using:

cmake \
-DCMAKE_INSTALL_PREFIX="${PREFIX}" \
-DCMAKE_CXX_COMPILER="${PREFIX}/bin/g++" \
-DCMAKE_C_COMPILER="${PREFIX}/bin/gcc" \
-DCMAKE_Fortran_COMPILER="${PREFIX}/bin/gfortran" \
-DEL_USE_64BIT_INTS=ON \
-DEL_HAVE_QUADMATH=OFF \
-DCMAKE_BUILD_TYPE=Release \
-DEL_HYBRID=ON \
-DBUILD_SHARED_LIBS=ON \
-DMATH_LIBS="-L${PREFIX}/lib -lopenblas -lm" \
-DINSTALL_PYTHON_PACKAGE=ON \
-DEL_BUILD_METIS=ON \
-DEL_DISABLE_VALGRIND=ON \
-DEL_DISABLE_PARMETIS=ON \
..

THEN

• Building Elemental 71fce6e (from May 3, 2016) succeeds.

• Building Elemental 0.87.2 fails with:

In file included from /u/gkollias/anaconda2/conda-bld/work/include/El/lapack_like.hpp:23:0,
                 from /u/gkollias/anaconda2/conda-bld/work/include/El.hpp:17,
                 from /u/gkollias/anaconda2/conda-bld/work/src/lapack_like/spectral/Schur.cpp:9:
/u/gkollias/anaconda2/conda-bld/work/include/El/lapack_like/funcs.hpp: In instantiation of ‘void El::schur::SDC(El::Matrix<T>&, El::Matrix<El::Complex<typename El::BaseHelper<Real>::type> >&, El::Matrix<T>&, bool, El::SDCCtrl<typename El::BaseHelper<Real>::type>) [with F = El::BigFloat; typename El::BaseHelper<Real>::type = El::BigFloat]’:
/u/gkollias/anaconda2/conda-bld/work/src/lapack_like/spectral/Schur.cpp:33:61:   required from ‘void El::Schur(El::Matrix<T>&, El::Matrix<El::Complex<typename El::BaseHelper<Real>::type> >&, const El::SchurCtrl<typename El::BaseHelper<Real>::type>&) [with F = El::BigFloat; typename El::BaseHelper<Real>::type = El::BigFloat]’
/u/gkollias/anaconda2/conda-bld/work/include/El/macros/Instantiate.h:111:1:   required from here
/u/gkollias/anaconda2/conda-bld/work/include/El/lapack_like/funcs.hpp:27:8: error: conversion from ‘int’ to non-scalar type ‘El::BigFloat’ requested
 struct SignCtrl
        ^
/u/gkollias/anaconda2/conda-bld/work/include/El/lapack_like/funcs.hpp:27:8: error: conversion from ‘int’ to non-scalar type ‘El::BigFloat’ requested
In file included from /u/gkollias/anaconda2/conda-bld/work/include/El/lapack_like.hpp:22:0,
                 from /u/gkollias/anaconda2/conda-bld/work/include/El.hpp:17,
                 from /u/gkollias/anaconda2/conda-bld/work/src/lapack_like/spectral/Schur.cpp:9:
/u/gkollias/anaconda2/conda-bld/work/include/El/lapack_like/spectral.hpp:808:8: note: synthesized method ‘constexpr El::SignCtrl<El::BigFloat>::SignCtrl()’ first required here
 struct SDCCtrl
        ^
/u/gkollias/anaconda2/conda-bld/work/include/El/lapack_like/spectral.hpp:821:8: note: synthesized method ‘constexpr El::SDCCtrl<El::BigFloat>::SDCCtrl()’ first required here
 struct SchurCtrl
        ^
In file included from /u/gkollias/anaconda2/conda-bld/work/src/lapack_like/spectral/Schur.cpp:15:0:
/u/gkollias/anaconda2/conda-bld/work/src/lapack_like/spectral/./Schur/SDC.hpp:976:28: note: synthesized method ‘constexpr El::SchurCtrl<El::BigFloat>::SchurCtrl()’ first required here
         SchurCtrl<Base<F>> schurCtrl;
                            ^

[poulson]

Perfect timing! Thank you for reporting this.

I will batch a fix for this with a few other changes that I'm making for 0.87.3 that will be released tonight.

[poulson]

This commit should fix this issue (and will be bundled later tonight in 0.87.3): vhttps://github.com/elemental/Elemental/commit/cfd5e58180e6263784b317e19d6e55f0cb05ad83

[gidiko]

I suspect tighter cmake-time checks from May 3 to now... but yes... after also adding

-DEL_HAVE_MPC=OFF

to avoid a linking error towards the end (it could fish the respective .a lib - since no .so lib under conda env... this was not there in the May snapshot, so getting no "complaints" with that):

[ 99%] Building CXX object CMakeFiles/El.dir/src/optimization/util/SOC/SquareRoot.cpp.o
[ 99%] Linking CXX shared library libEl.so
/usr/bin/ld: /u/gkollias/anaconda2/envs/_build/lib/libmpc.a(abs.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
/u/gkollias/anaconda2/envs/_build/lib/libmpc.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libEl.so.87-dev] Error 1
make[1]: *** [CMakeFiles/El.dir/all] Error 2
make: *** [all] Error 2

Elemental now builds nicely :)

[poulson]

What platform are you on? Ideally Elemental should prevent any such linking error by detecting whether or not the needed .so or .a exists.

[gidiko]

I am working with conda on RHEL:

[gkollias@dccxl001 ~]$ uname -srv
Linux 2.6.32-504.el6.x86_64 #1 SMP Tue Sep 16 01:56:35 EDT 2014
[gkollias@dccxl001 ~]$ conda --version
conda 4.2.13

To put things into context: I am building conda packages. The idea there is that compilers, libs, include files, python files, etc, all things necessary to build, link against, depend on, live within the anaconda installation directory. The binary artifacts in particular in the conda packages (=tarballs you build and upload in a repo so that people could say conda install <package> and get the package and its dependencies ala apt, yum, etc) use the trick of automatically being patched under the hood with utilities like PatchELF and this is basically what enables the "convenience".

I mean right now, I work in a machine where I cannot say sudo make or sudo make install as needed by Elemental or some of the dependencies; also this machine comes with an older gcc compiler (version 4.4.7) and I would therefore not be able (easily!) to compile Elemental (THE important dependency) or libSkylark (which is my FINAL target for packaging). But these are not problems when developing over this - let's call it the "conda/anaconda" platform (e.g. it allows compiling with gcc 4.8.5) :)

In a broader context: Now that an Elemental release is out I remembered the discussion here. The bottom line is that Elemental is truly exceptional software: our libSkylark builds on top, other excellent software like SmallK - with many more to follow!! - build on top. So trying to make all these efforts available through - as many as possible - easy to access paths (and to put my two cents in: conda packaging is perhaps the easiest such path) seems to be a good idea.

[poulson]

Thank you for the very detailed (and kind!) response. There are new/upcoming RHEL/Fedora packages available (listed under https://github.com/elemental/Elemental/releases/tag/v0.87.3) that can hopefully avoid the need for you to manually build the library. ( @rhl- has been kind enough to put them together and they are more or less through the review process. )