[Bug 173719] Review Request: openmpi - a new MPI implementation

bugzilla at redhat.com bugzilla at redhat.com
Thu Feb 16 19:03:11 UTC 2006


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request:  openmpi - a new MPI implementation


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719





------- Additional Comments From jvdias at redhat.com  2006-02-16 14:02 EST -------
Perhaps the simplest solution may be to simply ship openmpi in a way that does
not clash at all with lam, and that allows users to select use of either 
alternatives(8), or environment-modules, or home-grown solutions, but that
does not depend on the new environment-modules package or use alternatives(8)
in the .spec file. 

For example:
the 6 mpi* clashing binaries could be installed as:
  /usr/bin/om-$bin
(eg. /usr/bin/om-mpicc) , 

The clashing libraries could be installed in /usr/lib/openmpi . These
are:  
   libmpi*.so  ( clashes with lam RPM )
   libopal.so  ( clashes with opal RPM - the "Open Phone Abstraction Library"!)
Proably it is simpler just to put all openmpi libs in /usr/lib/openmpi .

and includes in /usr/include/openmpi.

Then links could be created in:
  /usr/share/openmpi/{bin,lib,include}
so that e.g.
  /usr/share/openmpi/bin/mpicc -> /usr/bin/om-mpicc
  /usr/share/openmpi/lib/libmpi.so -> /usr/lib/openmpi/mpi.so
etc.

There are as yet NO man-pages shipped in the openmpi distribution (another
reason why openmpi is still of "experimental" status IMHO).

Then existing lam users and the existing lam package would be totally 
unaffected.

The openmpi package should also provide pkg-config openmpi.pc files to 
easily provide the linker library and compiler include options to openmpi
using builds .

Users could decide to use alternatives ( ie. move the lam clashing executables
to /usr/bin/lam-*, and make /usr/bin/mpicc an alternative between 
/usr/bin/om-mpicc and /usr/bin/lam-mpicc ), or could use environment-modules
(set PATH, LD_LIBRARY_PATH to select between /usr/{lib,bin,include} and 
/usr/share/openmpi/{bin,lib,include} with modules). The environment-modules
scripts could actually be shipped in /usr/share/openmpi/environment-modules
and used at users' discretion, and we could also ship a script to setup 
alternatives(8). But the existing lam package could stay the same, and 
no new packages would be required by the new openmpi package.

I think the above is what I'll be aiming for with the Core release, unless 
there are any objections. 

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




More information about the fedora-extras-list mailing list