Bug#686926: liboctave-dev: creates broken .oct files when the OpenMPI flavor of HDF5 (libhdf5-openmpi-dev) is installed
On Sun, Mar 31, 2013 at 05:52:03PM -0700, Bradley M. Froehle wrote:
As an example of how confounding this is, just consider a simple example:
$ cat test.cpp
#include hdf5.h
#include mpi.h
int main() {
MPI::Init();
printf(I'm %d of %d\n, MPI::COMM_WORLD.Get_rank(),
MPI::COMM_WORLD.Get_size());
MPI::Finalize();
}
$ mpicxx -o test test.cpp
test.cpp: In function ‘int main()’:
test.cpp:4:3: error: ‘MPI’ has not been declared
test.cpp:5:28: error: ‘MPI’ has not been declared
test.cpp:5:56: error: ‘MPI’ has not been declared
test.cpp:6:3: error: ‘MPI’ has not been declared
Reversing the order of the includes as you suggest does allow the
compilation to succeed. My objection is primarily to the confusing nature
of the failure --- it's not at all clear what went wrong or why. I had to
run the compiler with -E and search through the preprocessed source to see
that the mpicxx.h header wasn't being included, then look to see the
condition by which it would be included, and then track down why those
conditions were not being met. A lot of grepping led to the H5public.h
header which I eventually tracked back to this issue. (Obviously the case
where I hit this was a lot more complicated than the toy example above and
it wasn't even clear initially that I should look into HDF5).
I agree, that is a confusing side-effect of this change.
Normally this is not an issue --- a developer would use mpicc or mpicxx
to
do the compilation
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.
Octave is not broken, it is simply using HDF5 in a C++ source file and
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
Yes, that is correct.
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
No, I believe this is wrong. Since hdf5-openmpi needs MPI, you should be
compiling with
$ mpicc -o hdf5test hdf5test.c -lhdf5
$ mpicxx -o hdf5test hdf5test.cc -lhdf5
This means that another solution to the mkoctfile problem would be to
invoke it as
CXX=mpicx mkoctfile ...
when compiling C++ code which directly (or indirectly) uses MPI.
I agree with you that my workaround is wrong, but I think your solution
is equally wrong, theoretically speaking. I am not (yet) an MPI user and
I am not really an HDF5 user either, except via Octave. But I would hope
for a set of HDF5 libraries that are true ABI-compatible drop-in
replacements for each other. I should ideally not even have to know
which HDF5 is installed when I compile a program that uses it, no matter
whether it's extra flags or a different compiler wrapper. Maybe this is
technically impossible, I don't know enough about MPI to say.
More practically, and more importantly, Octave users who are compiling
extensions from within Octave are yet another step removed from both the
compiler and the HDF5 library. They may not even be aware of HDF5 but
the compilation and linking of their oct-file will be affected.
Mkoctfile simply compiles extensions using the same set of flags and
libraries that Octave itself was built with. And those extensions should
work without needing to recompile if the HDF5 library is switched out.
Compiling them with CXX=mpicxx has the opposite effect.
--
mike
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#686926: liboctave-dev: creates broken .oct files when the OpenMPI flavor of HDF5 (libhdf5-openmpi-dev) is installed
CC'ing pkg-octave-devel since this impacts Octave packaging as well.
Bradley M. Froehle wrote:
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.
If you switch the order so mpi.h is included first does that fix it?
I'm not dismissing, just making sure I understand the problem.
I respectfully request that this patch be backed out until a better
solution can be
worked out. Totally disabling the MPI C++ bindings when including HDF5 is
not
an acceptable side effect.
I've looked into this bug a bit today and I'd suggest that instead the
`mkoctfile-mpi.diff` patch in src:octave (from bug #598227) be modified to
be something more like:
-: ${XTRA_CXXFLAGS=%OCTAVE_CONF_XTRA_CXXFLAGS%}
+: ${XTRA_CXXFLAGS=-I/usr/include/mpi -DOMPI_SKIP_MPICXX=1
-DMPICH_SKIP_MPICXX=1 %OCTAVE_CONF_XTRA_CXXFLAGS%}
That would contain the bug fix to Octave (which is the only place where the
bug seems to have surfaced).
Reverting this patch and moving the fix into Octave would be one
acceptable solution that should have the same effect as far as Octave
is concerned. IMHO this is still an HDF5 bug, see below.
Normally this is not an issue --- a developer would use mpicc or mpicxx to
do the compilation
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.
Octave is not broken, it is simply using HDF5 in a C++ source file and
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
Not ideal and could certainly affect users other than Octave.
--
mike
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#686926: [Pkg-octave-devel] Bug#686926: Bug#686926: liboctave-dev: creates broken .oct files when the OpenMPI flavor of HDF5 (libhdf5-openmpi-dev) is installed
On Mon, Sep 10, 2012 at 2:46 PM, Thomas Weber wrote: On Fri, Sep 07, 2012 at 09:11:34AM -0400, Mike Miller wrote: mkoctfile -DMPICH_SKIP_MPICXX=1 -DOMPI_SKIP_MPICXX=1 helloworld.cc I don't know enough about HDF5, but if it doesn't make use of the MPI C++ bindings at all, I'd argue this should be reassigned to hdf5 upstream so H5public.h would now contain: #ifdef H5_HAVE_PARALLEL # define MPICH_SKIP_MPICXX 1 # define OMPI_SKIP_MPICXX 1 # include mpi.h #endif Is my understanding correct that if I want to use HDF5 and one of MPICH or MPI with the C++ interface, I have lost? Could be, I hadn't thought through all the unintended consequences yet. On the flip side, the way it is now if I want to compile C++ with just HDF5, I have to link in libraries that I don't really need. -- mike ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
