Hi all,
I have been using the serialization library since
it is the way to go for communicating whole classes in Boost.MPI.
Previously, I didn't have any problems.
However, I now experience a strange problem. I have
successfully ran all my code in SDSC's Teragrid cluster (A cluster of Itanium
processors, running intel-linux), but when I tried to do the same thing in
NCSA's cluster (which is similarly composed of Itaniums with same OS) I just
can't build serialization library successfully. It says:
intel-linux.link.dll
bin.v2/libs/serialization/build/intel-linux/release/libboost_serialization-il-1_35.so.1.35.0
OBJREAD Error: Could not create mapping for
"bin.v2/libs/serialization/build/intel-linux/release/basic_oarchive.o".
icpc: error: problem during multi-file optimization compilation (code
1)
Both clusters use the same kernel (2.4.21), same
compiler suite (icc 9.1), same architecture, same mpixx
(/usr/local/apps/mpich-gm-1.2.6..14b-intel-r2/bin/mpicxx).
So, that was a little frustrating. But the
fact is that, it creates the multithreaded library (libboost_serialization-il-mt-1_35) even after the error. I gave it a try. Compilation is flawless, but
during runtime, main() is even not called [it seg faults immediately].When I
debug it, I get the following backtrace:
This GDB was configured as
"ia64-suse-linux"...
(gdb) run
Starting program:
/home/ac/aydinb/ParSPGEMM/testpar
Program received signal SIGSEGV, Segmentation
fault.
0x6000000000011ef0 in typeinfo for
boost::serialization::detail::extended_type_info_typeid_0 ()
(gdb)
bt
#0 0x6000000000011ef0 in typeinfo for
boost::serialization::detail::extended_type_info_typeid_0 ()
#1
0x4000000000103610 in
boost::serialization::detail::extended_type_info_typeid_0::less_than(boost::serialization::extended_type_info
const&) const (this=0x6000000000018650,
rhs=@0x6000000000018910) at
libs/serialization/src/extended_type_info_typeid.cpp:22
(gdb)
I said fine. Maybe the library was broken due to
errors in make / make install. Since we have the same settings, I copied the
libraries from SDSC (which works perfectly). Same error, same lines from the gdb
:(
Any insight why this might be the
case?
Thanks,
-- Aydin