Re: PetSc
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
Reply to:
- References:
- PetSc
- From: "Eray Ozkural \(exa\)" <erayo@cs.bilkent.edu.tr>
- Re: PetSc
- From: Adam C Powell IV <hazelsct@mit.edu>
- Re: PetSc
- From: Junichi Uekawa <dancer@netfort.gr.jp>
- Re: PetSc
- From: Brian Mays <brian@debian.org>
- Re: PetSc
- From: Junichi Uekawa <dancer@netfort.gr.jp>
- Re: PetSc
- From: Adam C Powell IV <hazelsct@mit.edu>
- Re: PetSc
- From: Junichi Uekawa <dancer@netfort.gr.jp>
- Re: PetSc
- From: Camm Maguire <camm@enhanced.com>