Has anyone seen a similar link error while building Parallel HDF5?:
...lib/libmpich.a(allreduce.o): relocation R_X86_64_32S against `MPIR_ThreadSingle' can not be used when making a shared object; recompile with -fPIC
.../lib/libmpich.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
I was successful in building PHDF5 with default options, but I didn't get any shared libs. So, I reconfigured with --enable-shared and got the error above.
I tried adding CFLAGS=-fPIC and CPPFLAGS=-fPIC to the configure command. I did "make clean" then "make" and got the same error. Could this error mean that I need to recompile mpich with -fPIC?
Has anyone seen a similar link error while building Parallel HDF5?:
...lib/libmpich.a(allreduce.o): relocation R_X86_64_32S against `MPIR_ThreadSingle' can not be used when making a shared object; recompile with -fPIC
.../lib/libmpich.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
I was successful in building PHDF5 with default options, but I didn't get any shared libs. So, I reconfigured with --enable-shared and got the error above.
I tried adding CFLAGS=-fPIC and CPPFLAGS=-fPIC to the configure command. I did "make clean" then "make" and got the same error. Could this error mean that I need to recompile mpich with -fPIC?
Yes, you are correct. As error message indicates, you have to recompile mpich with FPIC flag. We do not test shared parallel libraries. Please make sure to run all tests that come with the HDF5 library.
Thanks for the reply. I was actually using a prebuilt MPICH, but I will need to rebuild different versions of MPI anyway. Shared parallel libraries will allow me to easily swap out different PHDF5 builds with different MPI implementations.
Since this is untested, is there a strong chance I will run into issues?
Just so I know what I'm getting into, can others who have tried to use shared parallel libraries, please chime in with any experiences, good or bad?
John,
On Feb 23, 2010, at 6:13 PM, John Powell wrote:Has anyone seen a similar link error while building Parallel HDF5?:
...lib/libmpich.a(allreduce.o): relocation R_X86_64_32S against `MPIR_ThreadSingle' can not be used when making a shared object; recompile with -fPIC
.../lib/libmpich.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
I was successful in building PHDF5 with default options, but I didn't get any shared libs. So, I reconfigured with --enable-shared and got the error above.
I tried adding CFLAGS=-fPIC and CPPFLAGS=-fPIC to the configure command. I did "make clean" then "make" and got the same error. Could this error mean that I need to recompile mpich with -fPIC?
Yes, you are correct. As error message indicates, you have to recompile mpich with FPIC flag. We do not test shared parallel libraries. Please make sure to run all tests that come with the HDF5 library.
Elena
Thanks,
~John
Please test this very carefully/thoroughly. There is no common ABI
for MPI implementations, so if you build HDF5 with MPICH2 and link to
OpenMPI, you will run into problems as soon as you try to dup a
communicator (one impl uses opaque handles, the other uses pointers).
In fact, there's not even ABI compatibility between versions of a
given MPI implementation. OpenMPI and MPICH2 developers do not go
breaking the ABI willy-nilly, but sometimes a struct gets a larger
type, for example.
I know it's seductive to build HDF5 once for all MPI implementations
but given how disk space is so very much cheaper than developer time
trying to figure out bogosity, you might want to just have a bunch of
hdf5/mpi builds.
Now if you are instead going to build a specific version of MPICH2
with ifort, pgi, and gnu, and you are looking for a way to build a
single HDF5 that works with those three versions, you could likely get
away with that.
==rob
···
On Wed, Feb 24, 2010 at 12:03:28PM -0500, John Powell wrote:
Hi Elena,
Thanks for the reply. I was actually using a prebuilt MPICH, but I
will need to rebuild different versions of MPI anyway. Shared
parallel libraries will allow me to easily swap out different PHDF5
builds with different MPI implementations.
--
Rob Latham
Mathematics and Computer Science Division
Argonne National Lab, IL USA
Thanks for the advice. I am planning on having multiple PHDF5 builds - one for each different MPI implementation. I'll swap out the resulting PHDF5_MPI_XYZ shared library depending on the MPI implementation I want to use.
The thing I'm worried about is that Parallel HDF5 as a shared lib rather than static lib is not tested.
I'll be trying to get this working on Windows as well as Linux_64 and some other Unix variants, so I expect to run into some uncharted territory. Any experiences shared to help me stay out of trouble are much appreciated.
Thanks,
~John
···
Date: Wed, 24 Feb 2010 13:41:15 -0600
From: robl@mcs.anl.gov
To: hdf-forum@hdfgroup.org
Subject: Re: [Hdf-forum] Link error building ParallelHDF5 with --enable-shared
On Wed, Feb 24, 2010 at 12:03:28PM -0500, John Powell wrote:
>
> Hi Elena,
>
> Thanks for the reply. I was actually using a prebuilt MPICH, but I
> will need to rebuild different versions of MPI anyway. Shared
> parallel libraries will allow me to easily swap out different PHDF5
> builds with different MPI implementations.
Please test this very carefully/thoroughly. There is no common ABI
for MPI implementations, so if you build HDF5 with MPICH2 and link to
OpenMPI, you will run into problems as soon as you try to dup a
communicator (one impl uses opaque handles, the other uses pointers).
In fact, there's not even ABI compatibility between versions of a
given MPI implementation. OpenMPI and MPICH2 developers do not go
breaking the ABI willy-nilly, but sometimes a struct gets a larger
type, for example.
I know it's seductive to build HDF5 once for all MPI implementations
but given how disk space is so very much cheaper than developer time
trying to figure out bogosity, you might want to just have a bunch of
hdf5/mpi builds.
Now if you are instead going to build a specific version of MPICH2
with ifort, pgi, and gnu, and you are looking for a way to build a
single HDF5 that works with those three versions, you could likely get
away with that.
==rob
--
Rob Latham
Mathematics and Computer Science Division
Argonne National Lab, IL USA
