Rafael Laboissiere <rafael@laboissiere.net> writes: > When building packages with liboctave-dev >= 3.6.2-5 and when the > parallel version of HDF5 (libhdf5-openmpi-7) is installed, the loading of > the .oct files fails. For instance, with octave-signal: > > octave:1> which cl2bp > error: __which__: /usr/lib/i386-linux-gnu/octave/packages/signal-1.1.3/i486-pc-linux-gnu-api-v48+/cl2bp.oct: > failed to load: /usr/lib/i386-linux-gnu/octave/packages/signal-1.1.3/i486-pc-linux-gnu-api-v48+/cl2bp.oct: > undefined symbol: _ZN3MPI8Datatype4FreeEv Same here. All oct-files are broken (I somehow missed that because the testsuite of packages that I had tried did not test the Oct files…) This is not a critical problem for Wheezy because all our packages are currently compiled against the serial version. It is not a problem for octave-msh either because it is arch:all. > The symbol above is defined in /usr/lib/openmpi/lib/libmpi_cxx.so.0.0.1, > which means that cl2bp.oct should be linked against libmpi_cxx.so, which > is not the case. This reminds me of the problem I encountered when packaging octave-openmpi-ext. See: http://anonscm.debian.org/gitweb/?p=pkg-octave/octave-openmpi-ext.git;a=blob_plain;f=debian/README.Debian;hb=HEAD However I am not an OpenMPI specialist so I don't know if the bug is on our end or on the HDF5/OpenMPI side. -- .''`. Sébastien Villemot : :' : Debian Maintainer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594
Attachment:
pgpOd_7rUnu21.pgp
Description: PGP signature