On Wed, 22 Jun 2005, Pierre Valiron wrote:
> I guess whether it should be possible to automate somehow the
> version checking durint the lamboot process ?
Some months ago, I asked if it's possible to find the version of the
library used to compile/link a certain LAM/MPI binary; trying to get
rid of this problem in an automated way was one of the reasons. The
idea was to use a wrapper, like mpiexec, that does everything (lamboot
+ mpirun + lamhalt), with another wrapper for rsh (which means that it
would not work so well for other boot modules...) which would make
sure that the right paths would be set before executing the LAM/MPI
utilities; the one mpiexec wrapper is needed to do all steps at once
based on the same knowledge (the name of the binary application from
which versioning is extracted, maybe also other information related to
the compiler used). I don't know if this would work as a general
enough solution, as I have my own naming conventions for the MPI libs
installation directories and they would be used according to the
libraries found in the binary. This would also be more complicated or
even impossible for shared libs... But for the cases where it works it
has the advantage that no modifications to the MPI lib source code is
needed and also existing binaries do not need to be recompiled (the
last being quite important for me).
> This would imply that the preliminary boot phase would use an
> additional version-independant ack
I don't know if this is enough to eliminate all problems. In my
limited experience, the choice of compiler is not important, f.e. the
application binaries produced with mpif77 of a certain LAM/MPI version
compiled with the Intel compiler would be properly started by
lamboot/mpirun of the same LAM/MPI version compiled with g77; this
might not work so well with shared libs, though. So having only a
version dependent check would succeed in booting LAM/MPI, but the
application might still not start or work properly. Maybe some kind of
hash based on lib version, compiler, compiler version and location
(which are/will be all part of laminfo), etc. could be used to
identify the installation. This would however still provide no way of
identification for the older, already released versions... but the
lack of it could already be used as an indication, letting know the
user of the mismatch.
Another totally different idea is to rely on a shared directory to
which the user has rwx access to copy the needed executables (lamd,
hboot, tkill); this would again require some wrapper around lamboot,
mpirun and lamhalt.
A variation to the above would be to copy only a script called hboot
that sets the proper path and then calls the real hboot (and then lamd
and tkill would inherit $PATH from it).
I played with some of these solutions, but they have limitations, as
they rely on wrappers, shared directories or specific installation
directory names. So I don't regard any of them as generic enough to be
part of LAM/MPI...
--
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]
|
