CC'ing pkg-octave-devel since this impacts Octave packaging as well.
Bradley M. Froehle wrote:If you switch the order so mpi.h is included first does that fix it?
> The fix for this bug provided in 1.8.9-1~exp2 has cause me a good deal of
> headache today.
>
> For me, the issue is triggered as some C++ code containing:
>
> #include <hdf5.h> // sets OMPI_SKIP_MPICXX 1
> #include <mpi.h> // MPI C++ namespace now is NOT available
>
> Note that even trying to unset OMPI_SKIP_MPICXX before including mpi.h
> won't work
> because OMPI_MPI_H will still be defined and the mpi.h header won't be
> processed again.
I'm not dismissing, just making sure I understand the problem.
> Normally this is not an issue --- a developer would use mpicc or mpicxx to
> do the compilationOctave is not broken, it is simply using HDF5 in a C++ source file and
> and linking and this would automatically ensure that the correct mpi
> libraries are used. Octave
> is broken because it is using g++ and hacking in the MPI include directory
> without following it
> up with the necessary link flags.
does not care about or use MPI. However we do want to support
co-installation for users that do want both Octave and MPI. Octave
shouldn't have to care which flavor of HDF5 is installed. Consider
these simple examples:
$ cat hdf5test.c
#include <hdf5.h>
// C source file follows
main() {}
$ cat hdf5test.cc
#include <hdf5.h>
// C++ source file follows
main() {}
$ gcc -o hdf5test hdf5test.c -lhdf5
$ g++ -o hdf5test hdf5test.cc -lhdf5
Works if libhdf5-7 and libhdf5-dev are installed. If HDF5 were
providing a consistent interface this would also work with
libhdf5-openmpi-7 and libhdf5-openmpi-dev installed. As it stands now,
however, I need to compile with (assuming the patch is reverted)
$ gcc -I/usr/include/mpi -o hdf5test hdf5test.c -lhdf5
$ g++ -I/usr/include/mpi -DOMPI_SKIP_MPICXX -o hdf5test hdf5test.cc -lhdf5
or
$ g++ -I/usr/include/mpi -o hdf5test hdf5test.cc -lhdf5 -lmpi++ -lmpi