> 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.
Yes. I agree completely. Fundamentally I blame #598227 (http://bugs.debian.org/598227) which introduced the -I/usr/include/mpi flag to the mkoctfile build script. This was done in the name of pragmatism, but it really opens up a can of worms (as you can see). If that flag weren't there your experience would instead have been a "mpi.h" not found bug at compile time. A quick search on Google would hopefully have pointed you towards adding CC=mpicc CXX=mpicxx to the mkoctfile invocation and there wouldn't have been future issues. The plan, originally, was to have the octave headers depend on libhdf5-serial-dev (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598227#29). That would certainly resolve the issue, but it seems a bit overly restrictive. If only there was a way for the different variants of HDF5 to be simultaneously installable… -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
