nflicts between the apple supplied ompi and
your mpi. I use modules to force my mpi to the front of the PATH and
DYLD_LIBRARY_PATH variables.
Doug Reeder
On Dec 15, 2010, at 5:22 PM, Jeff Squyres wrote:
Sorry for the ginormous delay in replying here; I blame SC'10,
Thanksgiving, and the MPI
UPDATE:
Sorry for the delay but I wanted to make sure PGI was ok with me sharing
their workaround.
Further conversation with PGI tech support has yielded a solution. The
opal/util/if.c file has the following around line 63:
#include
Here is the explanation I have from PGI:
< Start Qu
do that for PGI only?
Thanks,
Dave
On Mar 1, 2011, at 11:50 AM, David Robertson wrote:
> Hi all,
>
> I am having trouble with PGI on Mac OS X 10.6.6. PGI's support staff
has informed me that PGI does not "support 64-bit shared library
creation" on the Mac. Therefore
Hi all,
I am having trouble with PGI on Mac OS X 10.6.6. PGI's support staff has
informed me that PGI does not "support 64-bit shared library creation"
on the Mac. Therefore, I have built Open MPI in static only mode
(--disable-shared --enable-static).
I have to do some manipulation to get m
Hi all,
I'm noticing a strange problem with Open MPI 1.4.2 on Mac OS X 10.6. We
use both Intel Ifort 11.1 and gfortran 4.3 on the same machine and
switch between them to test and debug code.
I had runtime problems when I compiled openmpi in my usual way of no
shared libraries so I switched t
I am using the following configure line:
CC=icc CXX=icpc F90=ifort FC=ifort F77=ifort ./configure
--disable-shared --enable-static
--prefix=/opt/intelsoft/openmpi/openmpi-1.3.2
once that completes and I execute make it fails very near the beginning
of the make process. It enters opal/asm and
WORLD "private" in
OpenMPI? If it is, is there a reason MPI_COMM_SELF does not behave the
same way? Is there a way to access MPI_COMM_WORLD's value?
If I have forgotten any details needed to debug this issue, please let
me know.
Thanks,
David Robertson
