[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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


------- Additional Comments From jvdias 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:
(eg. /usr/bin/om-mpicc) , 

The clashing libraries could be installed in /usr/lib/openmpi . These
   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:
so that e.g.
  /usr/share/openmpi/bin/mpicc -> /usr/bin/om-mpicc
  /usr/share/openmpi/lib/libmpi.so -> /usr/lib/openmpi/mpi.so

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 

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]