Bug#686926: liboctave-dev: creates broken .oct files when the OpenMPI flavor of HDF5 (libhdf5-openmpi-dev) is installed

[Mike Miller]

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