3.7.0 build failure: invalid conversion from ‘void*’ to ‘Mat'

[Drew Parsons]

I'm preparing PETSc/SLEPc in Debian. 3.7 versions are in the Debian experimental repository. PETSC 3.7.2, SLEPc 3.7.1 and petsc4py 3.7.0 have all built successfully. slepc4py 3.6.0 also built successfully with the 3.6 versions.

But slepc4py 3.7.0 fails to build with the following error:

creating build/temp.linux-x86_64-2.7/src
mpicxx -pthread -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -DPETSC_DIR=/usr/lib/petscdir/3.7 -DSLEPC_DIR=/usr/lib/slepcdir/3.7 -I/usr/lib/slepcdir/3.7/include -I/usr/lib/openmpi/include/openmpi -I/usr/lib/openmpi/include/openmpi/opal/mca/event/libevent2021/libevent/include -I/usr/lib/openmpi/include/openmpi/opal/mca/event/libevent2021/libevent -I/usr/lib/openmpi/include -I/usr/include/scotch -I/usr/include/suitesparse -I/usr/include -I/usr/lib/petscdir/3.7.2/x86_64-linux-gnu-real/include -Isrc/include -I/usr/lib/python2.7/dist-packages/petsc4py/include -I/usr/include/python2.7 -c src/SLEPc.c -o build/temp.linux-x86_64-2.7/src/SLEPc.o
In file included from src/SLEPc.c:3:0:
src/slepc4py.SLEPc.c: In function ‘PyObject* __pyx_pf_8slepc4py_5SLEPc_2BV_34setMatrix(PySlepcBVObject*, PyPetscMatObject*, int)’:
src/slepc4py.SLEPc.c:12054:13: error: invalid conversion from ‘void*’ to ‘Mat {aka _p_Mat*}’ [-fpermissive]
   __pyx_v_m = __pyx_t_1;
             ^

Has anyone else bumped into this build error? What might be causing it? Should the assignment be done with an explicit cast?

Using python 2.7.12. Compiler version g++ 5.4.0, invoked as mpicxx managed by libopenmpi-dev 1.10.3-3.

More complete log (building via dpkg-buildpackage) is attached.

[Lisandro Dalcin]

Apply patch from commit a93f720 (https://bitbucket.org/slepc/slepc4py/commits/a93f720cf03e48aa9bb84283d7b2f5423d0b6cfa/raw/), but then you need to regenerate the C wrappers with Cython (python setup.py build_src --force), then generate a patch for src/slepc4py.SLEPc.c. Add this patch to deb build recipe, and you should be done.

Alternatively, you could just patch the Cython-generated C wrapper code (src/slepc4py.SLEPc.c) and add explicit casts in the offending places.

PS: Any reason you are building with C++? I would recommend against it. Using plain C with C99 complex numbers should be enough.

[Drew Parsons]

Thanks Lisandro, a93f720 works a charm.

I'm not explicitly configuring for C++. It comes out that way automatically from setup.py. The Debian script (debian/rules) uses dh_auto_build, which calls

python setup.py build --force

CXXONLY is then generated from "running build_ext". The same happens for petsc4py.

The Debian scripts are in the debian subdir at http://anonscm.debian.org/cgit/debian-science/packages/slepc4py.git/, with 3.7.0 in the experimental branch.

Our build logs are available at https://buildd.debian.org/status/package.php?p=slepc4py&suite=unstable (3.6.0) or https://buildd.debian.org/status/package.php?p=slepc4py&suite=experimental (3.7.0).

[Lisandro Dalcin]

If petsc4py/slepc4py are using C++, it is because PETSc (and then SLEPc) were built with C++. Are you the one building these packages? Unless it is really needed or there is a good reason not to do so, I would build PETSc with plain C.

[Drew Parsons]

Looks like CXXONLY is coming out of our PETSc configuration, from PETSC_LANGUAGE defined in /usr/lib/petsc/lib/petsc/conf/petscvariables.

For petsc 3.6.4.dfsg1-2 (or from 3.7.2.dfsg1-1exp1) we had tried to remove any configured language (both --with-clanguage=C++ --with-c-support) from petsc in http://anonscm.debian.org/cgit/debian-science/packages/petsc.git/commit/?id=31198384a9b15d53c7102e5a3a9683fce8e0098d The motivation was to simplify the build by removing excess unneeded configure options.

But apparently we had to configure with --with-clanguage=C++, reinstated in http://anonscm.debian.org/cgit/debian-science/packages/petsc.git/commit/?id=f8cc58b4f5be3566d7b92075154b492fcd51a4ad

Should we try reconfiguring petsc using --with-clanguage=C instead?

[Lisandro Dalcin]

Do you know why --with-clanguage=C++ had to be reinstated? Not a big deal, anyway.

[Drew Parsons]

Reading through the histories, --with-clanguage=C++ --with-c-support was originally added to help some libraries work with PETSc, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576799. But --with-c-support is no longer a configure option. I'll ask Nico why he wasn't able to remove the --with-clanguage=C++ option.

[Drew Parsons]

Nico says he may have reinstated --with-clanguage=C++ while trying to resolve the fPIC problem in https://bitbucket.org/petsc/petsc/issues/132/fpic-not-added-on-next-ubuntu-1610.

It could be that we can manage well enough without that C++ option now, but I'll need to check whether the requirement for it in debian bug#576799 (supporting a 3rd party C++ library) still holds.

[Lisandro Dalcin]

I think the issues raised in debian bug#576799 no longer apply. TAO is now part of PETSc. If you build PETSc with C, you can safely include header files in C++ code.