I've been using openmpi-1.2.x for 2 years to dynamically create python bindings for my application code. I've just downloaded and installed openmpi-1.3.2, and I now get the following error when trying to run python with one of my bindings:
/data/python/current/bin/python: symbol lookup error: /data/mpi/gcc-4.3.2/openmpi-1.3.2/lib/openmpi/mca_paffinity_linux.so: undefined symbol: mca_base_param_reg_int All of my regular executables work fine. To build one of my bindings I use the following configure line: mpic++ -pthread -shared -Xlinker -R/data/vendors/gcc/silo/lib/:/data/vendors/gsl-1.9/lib/:/data/mpi/gcc-4.3.2 /openmpi-1.3.2/lib:/data/gcc/current/lib:/home/9te/work/Sn/build/debug/denov o/src/pykba:/home/9te/work/Sn/build/debug/denovo/src/pykba/..:/home/9te/work /Sn/build/debug/lib -o _hybrid.so hybrid_wrap.o SC.pt.o Database.o denovo.o Mavric_Parser.o Source.o Mat.o Objects.o Map.o Viz.o Angles.o MC_Manager.o WW.o Problem_Output.o -L/home/9te/work/Sn/build/debug/lib -ldenovo_kba_utils -ldenovo_kba -ldenovo_source -ldenovo_material -ldenovo_angle -ldenovo_database -ldenovo_meshing -ldenovo_utils -ldenovo_comm -ldenovo_harness -ldenovo_release -L/data/vendors/gcc/trilinos/ompicxx/lib/ -lamesos -laztecoo -lepetraext -lepetra -lteuchos -ltriutils -L/data/vendors/gsl-1.9/lib/ -lgsl -lgslcblas -L/data/vendors/gcc/atlas/lib/ -llapack -lf77blas -lcblas -latlas -L/data/vendors/gcc/silo/lib/ -lsiloh5 -L/data/vendors/gcc/hdf5/lib/ -lhdf5 -lz -L/home/data/gcc/gcc-4.3.2/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2 -L/home/data/gcc/gcc-4.3.2/bin/../lib/gcc -L/home/data/gcc/gcc-4.3.2/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../.. -lgfortranbegin -lgfortran -lm -lgcc_s -lm I noticed on the mail archive a post related to this issue back in 2005 ( From: Jeff Squyres (jsquyres_at_[hidden]) Date: 2005-09-15 15:32:21); however, I am assuming that this issue has been resolved since then. Is there something I need to do extra? I know the symbol in question is defined in libopen-pal.so, so it does exist, and mpic++ does include it on the link-line. As mentioned in the older post, LD_LIBRARY_PATH tinkering will not fix the problem. Any help is greatly appreciated. Tom -- Tom Evans Radiation Transport and Shielding Nuclear Science and Technology Division ------------------------------------------------ (865) 576-3535 Oak Ridge National Laboratory (865) 574-9619 fax PO Box 2008 MS6172 evan...@ornl.gov Oak Ridge, TN 37831-6170 www.ornl.gov/sci/radiation_transport_criticality ------------------------------------------------
