Thanks again Gilles,
You might be on to something. Dynamic libraries sound like something
a Python developer might love (no offense intended to the stereotype).
It would also explain why the build went smoothly but the test run
crashed. I am going to try putting an RPATH variable in the environment
and rebuilding.
Ray
On 6/12/2015 7:15 AM, Gilles Gouaillardet wrote:
Ray,
one possibility is one of the loaded library was built with -rpath and
this causes the mess
an other option is you have to link _error.so with libmpi.so
Cheers,
Gilles
On Friday, June 12, 2015, Ray Sheppard <rshep...@iu.edu
<mailto:rshep...@iu.edu>> wrote:
Hi Gilles,
Thanks for the reply. I completely forgot that lived in the main
library. ldd doesn't show that it read my LD_LIBRARY_PATH (I also
push out an LPATH variable just for fun). I force modules to
echoed when users initialize them. You can see OpenMPI was
visible to H5py. Now I wonder why it didn't pick it up... Thanks
again.
Ray
GMP arithmetic library version 5.1.1 loaded.
MPFR version 3.1.1 loaded.
Mpc version 1.0.1 loaded.
gcc version 4.9.2 loaded.
Moab Workload Manager scheduling and management system version
7.1.1 loaded.
Python programming language version 2.7.3 loaded.
Perl programming language version 5.16.2 loaded.
Intel compiler suite version 15.0.1 loaded.
OpenMPI libraries (Intel) version 1.8.4 loaded.
TotalView version 8.15.0-15 loaded.
FFTW (Intel, Double precision) version 3.3.3 loaded.
hdf4 version 4.2.10 loaded.
Curl version 7.28.1 loaded.
HDF5 (MPI) version 1.8.14 loaded.
netcdf-c version 4.3.3 loaded.
netcdf-fortran version 4.4.1 loaded.
Gnuplot graphing utility version 4.6.1 loaded.
[rsheppar@h2 ~]$ ldd
/N/dc2/projects/ray/quarry/h5py/h5py-2.5.0/build/lib.linux-x86_64-2.7/h5py/_errors.so
linux-vdso.so.1 => (0x00007fff39db7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007facfe887000)
libc.so.6 => /lib64/libc.so.6 (0x00007facfe4f3000)
/lib64/ld-linux-x86-64.so.2 (0x00007facff049000)
On 6/11/2015 8:09 PM, Gilles Gouaillardet wrote:
Ray,
this symbol is defined in libmpi.so.
can you run
ldd
//N/dc2/projects/ray/quarry/h5py/h5py-2.5.0/build/lib.linux-x86_64-2.7/h5py//_errors.so
and make sure this is linked with openmpi 1.8.4 ?
Cheers,
Gilles
On 6/12/2015 1:29 AM, Ray Sheppard wrote:
Hi List,
I know I saw this issue years ago but have forgotten the
details. I looked through old posts but only found about half a
dozen pertaining to WinDoze. I am trying to build a Python
(2.7.3) extension (h5py) that calls HDF5 (1.8.14). I built both
the OpenMPI (1.8.4) and the HDF5 modules so I know they are
consistent. All goes well until I try to run the tests. Then I
get:
ImportError:
/N/dc2/projects/ray/quarry/h5py/h5py-2.5.0/build/lib.linux-x86_64-2.7/h5py/_errors.so:
undefined symbol: ompi_mpi_info_null
I am not sure I completely trust the h5py package but I don't
have a real good reason for believing that way. I would
appreciate it if someone could explain where ompi_mpi_info_null
is defined and possibly a way to tell Python about it. Thanks!
Ray
_______________________________________________
users mailing list
us...@open-mpi.org <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');>
Subscription:http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this
post:http://www.open-mpi.org/community/lists/users/2015/06/27117.php
_______________________________________________
users mailing list
us...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2015/06/27119.php
