On Thu, 18 Nov 2004, Jeff Squyres wrote:
> We're toying around with a few ways to still have "one" installation
> (e.g., have something like libmpi_g++.so, libmpi_icpc.so, etc., and
> have the wrapper intelligently choose between them), but haven't had
> time to come up with a final solution there yet.
Something like this was done for SCore (http://www.pccluster.org,
based on MPICH), where the underlying compiler flavour was chosen
like:
mpif77 -compiler pgi
(for such a long option name, I would have preferred --compiler ;-))
This would ensure that the right flags, paths and libraries are used
while still having a single installation tree - this is something that
I would like to see as quite some part of the current LAM installation
tree is unchanged (for example, it doesn't really matter if hboot is
compiled with gcc, icc or pgcc; the man pages are identical). It would
be even nicer if the compiler dependent parts only would be
installable, such that an installation tree that contains stuff for
gcc and Intel compilers can easily have added the PGI specific stuff,
without having to install the whole tree (= loss of time for
recompilation and QA).
However, one part that I felt was missing is the propagation of the
compiler settings to runtime, mainly the availability of shared
libraries. I know that this is a hard problem, so I won't pretend to
have a way to solve it. But some part of the problem can be solved if
(still assuming LAM's start-up model) the daemon could set/add a
compiler-specific LD_LIBRARY_PATH before starting the process or even
could copy some .so files to a local temporary directory for the case
of non-shared compiler/libraries installation (this should be
configurable, as some .so files are not redistributable).
--
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu_at_[hidden]
|
