I don't really care, but note that loop_spawn was created by me to test a very
specific user-reported problem. It should "self-throttle" - i.e., the entire
idea is that comm_spawn "blocks" until the system has room for another process,
and then starts it. If that isn't working correctly, then OM
FWIW: I build OMPI on Mac OS-X (Snow Leopard) every day, without adding any
extra flags, without problem. The citation below relates to something from a
long time ago, I believe - haven't seen that problem in quite some time.
I do not, however, use PGI. We regularly have problems with PGI on a v
Matthew,
I have the same type of error on a completely different software
package on Mac OS X. The error occurs because of the way that Mac OS
X searches for -lutil. If the libutil.a ORTE needs is theirs, i.e.,
not the system libutil.dylib, then you have exactly the same problem I
did.
I think this is a good idea.
I have spent a fair amount of time in the past analyzing timeouts from this set
of tests. I had to figure out if it was an actual timeout or if the test was
just running very slowly.
In fact, I see that sometime in the past I throttled back the number of
iterations
I hope this problem merits being posted here.
On OS X (Snow Leopard, and Lion), I cannot seem to build Open MPI.
After a lot of building, I get the error:
/bin/sh ../../../libtool --tag=CC --mode=link
/opt/pgi/osx86-64/10.9/bin/pgcc -DNDEBUG -O2 -Msignextend -V
-export-dynamic -o orte-clean
This is a question about ompi-tests/ibm/dynamic. Some of these tests
(spawn, spawn_multiple, loop_spawn/child, and no-disconnect) exercise
MPI_Comm_spawn* functionality. Specifically, they spawn additional
processes (beyond the initial mpirun launch) and therefore exert a
different load on a
