jsquyres [Sat, 15 Dec 2012 13:10:14 +0000] rev 21067
Remove the comment about OSCAR being long gone; it's apparently alive
and well.
Packaging change; no CMR required.
jsquyres [Sat, 15 Dec 2012 13:08:04 +0000] rev 21066
Remove the comment about OSCAR being long gone; it's apparently alive
and well.
jsquyres [Sat, 15 Dec 2012 13:09:08 +0000] rev 21065
Remove the comment about OSCAR being long gone; it's apparently alive
and well.
Packaging change; no CMR required.
rhc [Fri, 14 Dec 2012 17:00:44 +0000] rev 21064
Refs #3429
Fix bug reported by FreyGuy19713: in cases where HNP node has multiple entries in a hostfile or other allocation, we need to track the total slots allocated to that node.
jsquyres [Fri, 14 Dec 2012 16:34:20 +0000] rev 21063
Refs #3422
* Add some comments in the *-wrapper-data-txt.in files just so that
someone doesn't forget in the future why we link in what we do in
the MPI and ORTE wrapper compilers.
* Update ompi_wrapper_script.in to match the new behavior.
* Update orte_wrapper_script.in to support --openmpi:linkall (which
is a no-op in this case)
hjelmn [Thu, 13 Dec 2012 23:18:53 +0000] rev 21062
btl/vader: fix bug in single copy code that could cause ob1 sends to not get marked complete.
cmr:v1.7
jsquyres [Thu, 13 Dec 2012 22:31:37 +0000] rev 21061
Put back the static-library-detection stuff from r27668, with some
additional functionality. Rationale (refs #3422):
* Normal MPI applications only ever use the MPI API. Hence, -lmpi is
sufficient (they'll never directly call ORTE or OPAL
functions). This is arguably the most common case.
* That being said, we do have some test programs (e.g., those in
orte/test/mpi) that call MPI functions but also call ORTE/OPAL
functions. I've also written the occasional MPI test program that
calls opal_output, for example (there even might be a few tests in
the IBM test suite that directly call ORTE/OPAL functions).
* Even though this is not a common case, these applications should
also compile/link with mpicc.
* So we should add a --openmpi:linkall option that will also link
in whatever is necessary to call ORTE/OPAL functions
* Yes, we could hard-code "-lopen-rte -lopen-pal" in Makefiles, but
we do reserve the right to change those library names and/or add
others someday, so it's better to abstract out the names and let
the wrapper supply whatever is necessary.
* ORTE programs, however, are different. They almost always call OPAL
functions (e.g., if they want to send a message, they must use the
OPAL DSS). As such, it seems like the ORTE programs should always
link in OPAL.
Therefore:
* Add undocumented --openmpi:linkall flag to the wrapper compilers.
See the comment in opal_wrapper.c for an explanation of what it
does. This flag is only intended for Open MPI developers -- not
end users. That's why it's undocumented.
* Update orte/test/mpi/Makefile.am to add --openmpi:linkall
* Make ortecc/ortec++'s wrapper data text files always explicitly
link in libopen-pal
jsquyres [Thu, 13 Dec 2012 15:03:48 +0000] rev 21060
Ensure to set Fortran ierr properly at the end of
MPI_Get_processor_name. Thanks to LANL for spotting the issue.
jsquyres [Tue, 11 Dec 2012 23:08:14 +0000] rev 21059
Temporarily revert r27662 and r27667 because something wonky is
happening on OS X. Grumble...
jsquyres [Tue, 11 Dec 2012 21:25:00 +0000] rev 21058
If a user supplies both (some form of --static) and (some form of
--dynamic), use the one that was farthest to the right on the command
line.