On 1/17/14 6:28 PM, "Paul Hargrove" <phhargrove@lbl.gov> wrote:

I am trying to build the 1.7 nightly tarball (1.7.4rc2r30303) on a Linux/PPC system with the xlc-11.1 compilers configured for 32-bit output:

$ export OBJECT_MODE=32
$ [pathto]/configure CC=xlc CXX=xlC FC=xlf90 --enable-debug --prefix=...

The build fails with:

Making all in mpi/cxx
make[2]: Entering directory `/gpfs-biou/phh1/OMPI/openmpi-1.7.4-latest-linux-ppc32-xlc-11.1/BLD/ompi/mpi/cxx'
  CXX      mpicxx.lo
"/home/phh1/SCRATCH/OMPI/openmpi-1.7.4-latest-linux-ppc32-xlc-11.1/openmpi-1.7.4rc2r30303/opal/threads/mutex.h", line 292.15: 1540-0274 (S) The name lookup for "opal_atomic_add_64" did not find a declaration.
make[2]: *** [mpicxx.lo] Error 1

My guess is due to the ILP31 target, there might not *be* any atomic 64-bit add.
However, my Linux/ARM build with gcc worked fine, so clearly (to me) there is support for ILP32 systems.

The OBJECT_MODE=64 case gets past this point (but fails building fortran support - report coming soon).

I will accept "we don't support this target", but am reporting this for completeness.

Ugh, this is a 32 bit RISC problem; we don't have a 64 bit atomic on a 32 bit platform.  People are supposed to check to see if there's 64 bit atomic support, but that clearly hasn't been happening.  I've fixed this compile error, but there are still two places in the code base (bcol-basesmuma and coll-ml) that blindly use 64 bit atomics and I don't have time to fix those.  I'll file a CMR for the core fix and bugs about the components, but I'm not hopeful people will fix them before the 1.7.4 release.  Sigh.


  Brian W. Barrett
  Scalable System Software Group
  Sandia National Laboratories