Hi Mike:
Sorry that you'll get this twice. The first time around I accidentally
replied only to you. Please read on for responses inline.
On Sun, Mar 31, 2013 at 4:08 PM, Mike Miller wrote:
> CC'ing pkg-octave-devel since this impacts Octave packaging as well.
Thanks.
> 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// sets OMPI_SKIP_MPICXX 1
> > #include // 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.
As an example of how confounding this is, just consider a simple example:
$ cat test.cpp
#include
#include
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).
> > 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
> // C source file follows
> main() {}
>
> $ cat hdf5test.cc
> #include
> // 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.
Cheers,
Brad
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
