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