Subject:  fix name conflict when both ugni and scif installed on system
Description: This mod fixes two name conflicts between the ugni and scif btls.
References:4771
Closes:4771

cmr=v1.8.2:reviewer=hjelmn
Silence warning about set-but-unused var
Silence unused var warning
Silence used-before-set var warning
Protect against problems if someone passes us thru a pipe and then abnormally terminates the pipe early
Correct trivial typos in man files and FUNC_NAME variables.
Patch provided by Fujitsu (Kawashima, Takahiro)

cmr=v1.8.2:reviewer=jsquyres
AUTHORS: Add Howard Pritchard
MXM: update min required version for mxm as 2.1+
Per RFC: Remove des_src and des_dst members from the
mca_btl_base_segment_t and replace them with des_local and des_remote

This change also updates the BTL version to 3.0.0. This commit does
not represent the final version of BTL 3.0.0. More changes are coming.

In making this change I updated all of the BTLs as well as BTL user's
to use the new structure members. Please evaluate your component to
ensure the changes are correct.

RFC text:

This is the first of several BTL interface changes I am proposing for
the 1.9/2.0 release series.

What: Change naming of btl descriptor members. I propose we change
des_src and des_dst (and their associated counts) to be des_local and
des_remote. For receive callbacks the des_local member will be used to
communicate the segment information to the callback. The proposed change
will include updating all of the doxygen in btl.h as well as updating
all BTLs and BTL users to use the new naming scheme.

Why: My btl usage makes use of both put and get operations on the same
descriptor. With the current naming scheme I need to ensure that there
is consistency beteen the segments described in des_src and des_dst
depending on whether a put or get operation is executed. Additionally,
the current naming prevents BTLs that do not require prepare/RMA matched
operations (do not set MCA_BTL_FLAGS_RDMA_MATCHED) from executing
multiple simultaneous put AND get operations. At the moment the
descriptor can only be used with one or the other. The naming change
makes it easier for BTL users to setup/modify descriptors for RMA
operations as the local segment and remote segment are always in the
same member field. The only issue I forsee with this change is that it
will require a little more work to move BTL fixes to the 1.8 release
series.
spml_yoda_getreq.c: fix compile error related to r32196
usnic: Fix compile errors related to r32196
help-orterun.txt: wrap long messages, clarify new messages

Clarify the new -x/mca_base_env_list help messages.
Remove debug
osc/rdma: fix warning

cmr=v1.8.2:reviewer=rhc
Fix typo in r32196
NOTE: this modifies the MPI-RTE interface

We have been getting several requests for new collectives that need to be inserted in various places of the MPI layer, all in support of either checkpoint/restart or various research efforts. Until now, this would require that the collective id's be generated at launch. which required modification
s to ORTE and other places. We chose not to make collectives reusable as the race conditions associated with resetting collective counters are daunti
ng.

This commit extends the collective system to allow self-generation of collective id's that the daemons need to support, thereby allowing developers to request any number of collectives for their work. There is one restriction: RTE collectives must occur at the process level - i.e., we don't curren
tly have a way of tagging the collective to a specific thread. From the comment in the code:

 * In order to allow scalable
 * generation of collective id's, they are formed as:
 *
 * top 32-bits are the jobid of the procs involved in
 * the collective. For collectives across multiple jobs
 * (e.g., in a connect_accept), the daemon jobid will
 * be used as the id will be issued by mpirun. This
 * won't cause problems because daemons don't use the
 * collective_id
 *
 * bottom 32-bits are a rolling counter that recycles
 * when the max is hit. The daemon will cleanup each
 * collective upon completion, so this means a job can
 * never have more than 2**32 collectives going on at
 * a time. If someone needs more than that - they've got
 * a problem.
 *
 * Note that this means (for now) that RTE-level collectives
 * cannot be done by individual threads - they must be
 * done at the overall process level. This is required as
 * there is no guaranteed ordering for the collective id's,
 * and all the participants must agree on the id of the
 * collective they are executing. So if thread A on one
 * process asks for a collective id before thread B does,
 * but B asks before A on another process, the collectives will
 * be mixed and not result in the expected behavior. We may
 * find a way to relax this requirement in the future by
 * adding a thread context id to the jobid field (maybe taking the
 * lower 16-bits of that field).

This commit includes a test program (orte/test/mpi/coll_test.c) that cycles 100 times across barrier and modex collectives.
Fortran: put type(c_ptr) interfaces in a separate file in the TKR mpi module

Older gfortran compilers (e.g., the gfortran that ships in RHEL5) do
not support ISO_C_BINDING, and therefore do not support the
TYPE(C_PTR) type.  As such, they cannot support the overloaded
interfaces for MPI_WIN_ALLOCATE_SHARED and MPI_SHARED_QUERY that are
mandated in MPI-3.

So we separate those interfaces out into a separate .F90 file that is
#include'd in the tkr mpi.F90 file.  In this separate .F90 file, we
use an #if to determine whether the compiler supports ISO_C_BINDING or
not.

Also re-jiggered the order of testing in ompi_setup_mpi_fortran.m4: we
now need to test whether the compiler supports ISO_C_BINDING even when
we're only building the mpi module (not strictly when we're building
the mpi_f08 module).

Finally, tweaked the use-mpi-tkr/Makefile.am to:

* Add some proper dependencies for mpi.F90
* Allow the general AM compilation to be used instead of supplying a
  specific rule for compiling mpi.F90

cmr=v1.8.2:ticket=#4736
build: remove distro id from src.rpm filename, select md5 packing algorithm for
consistency across different distros: src.rpm create on one distro can be unpacked on
another when same packing algorithm used on both.

reviewed by Jeff
cmr=v1.8.2:reviewer=ompi-rm1.8
Fix one spot missed by recent commit
Checkpoint