Re: PetSc

[Peter Cordes <peter@llama.nslug.ns.ca>]

On Fri, Jan 12, 2001 at 11:23:53AM -0500, Camm Maguire wrote:
> Greetings!
> 
> Junichi Uekawa <dancer@netfort.gr.jp> writes:
> 
> > In Thu, 11 Jan 2001 12:14:02 -0500 Adam C Powell IV <hazelsct@mit.edu> cum veritate scripsit :
> > 
> > > Right.  The other problem is that mpirun takes different arguments for
> > > mpich and lam, and
> > > PETSc comes with a compatibility wrapper script "mpirun.lam" which takes
> > > arguments in mpich
> > > format.  
> > 
> > Hmmm.. that's very interesting. 
> > 
> 
> My understanding is that the most recent lam's mpirun can take the
> same syntax as mpich's, though it has additional options as well.
> Could be mistaken on this, as am not too familiar with mpich.  Here is
> the latest synopsis:
> 
>        mpirun [-fhvO] [-c <#> | -np <#>] [-D | -wd <dir>] [-ger |
>               -nger] [-c2c | -lamd] [-nsigs] [-nw | -w] [-nx]
>               [-pty] [-s <node>] [-t | -toff | -ton] [-x
>               VAR1[=VALUE1][,VAR2[=VALUE2],...]]  [<nodes>]
>               <program> [-- <args>]
> 
>        mpirun [-fhvO] [-D | -wd <dir>] [-ger | -nger] [-lamd |
>               -c2c] [-nsigs] [-nw | -w] [-nx] [-pty] [-t | -toff
>               | -ton] [-x VAR1[=VALUE1][,VAR2[=VALUE2],...]]
>               <schema>
> 
> 
> > > Oh- and mpich doesn't have shared libs, so when you link -mpi
> > > and
> > > /etc/alternatives points to mpich, there are dangling symlinks for
> > > libmpi.so. :-(
> > 
> > Actually it is possible to build shared library for mpich, and
> > I tried it. It was not very exciting. 
> > 
> 
> Not too exciting?  Sounds like real progress to me!  Is the latest
> mpich package equipped with these shared libs?=
> 
> > Hmmm.. I didn't know there was a dangling symlink. 
> > Okay... please file a bug.
> > 
> > 
> > 
> > Ah, yes. This is a nightmare, trying to compile against mpich AND lam.
> > 
> 
> Maybe its not so bad.  We have the scalapack package as an example.
> 
> Meanwhile, I've been discussing the binary compatibility issue with
> the lam authors, and it may not be quite as difficult as we had
> thought, (only if both implementations use shared libs, of course).
> Even if this were achieved, we'd have a Debian problem:  with the
> alternatives scheme, compiling against -lmpi will produce a binary
> with ldd reporting linkage against liblam or libmpich -- the compiler
> goes straight through the symbolic links.  Maybe this can be handled
> with a compiler/linker flag, but otherwise, we'd have to fall back on
> diversions (e.g. dpkg-divert) for libmpi.

 You could have libmpi pointing to whichever one you wanted, and have that
binary tell the linker to refer to it as libmpi.
 
 ld has an option:
    -soname name
              When  creating an ELF shared object, set the inter-
              nal DT_SONAME field to the specified name.  When an
              executable is linked with a shared object which has
              a DT_SONAME field, then when the executable is  run
              the  dynamic linker will attempt to load the shared
              object specified by the DT_SONAME field rather than
              the using the file name given to the linker.


 This would require that the LAM library and the MPICH libraries were both
compiled with -soname libmpi, since there doesn't seem to be a way to tell
ld to ask for a certain library in the executable being linked to be called
by a different name.  That would be a nice capability, though!  Maybe there
is a way to do it with linker scripts.  I haven't read all the stuff in
binutils-doc yet.  (Try the ld info page.)

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@llama.nslug. , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE