On Thu, Feb 09, 2006 at 11:33:46PM -0500, Brian Barrett wrote:
> On Feb 9, 2006, at 6:36 PM, Ross Boylan wrote:
[stuff about different lam versions snipped]
> > There was a warning about mixing versions. I had done a lamboot under
> > the old version. It was easy to shut it down and restart.
> >
> > But---do I need to rebuild everything that uses lam? In particular, R
> > uses MPI via a dynamically loaded library. Does that library need
> > to be
> > rebuilt, and if so will other users on the old lam find it doesn't
> > work
> > for them?
>
> If LAM/MPI was built as static libraries, yes you will either need to
> install the new version of LAM into a new location or recompile every
> application that linked in the LAM libraries. If the R module linked
> in the static libraries, then yes, it would have to be recompiled.
> This is one of those places where shared libraries has some benefit -
> LAM's public API has been pretty stable for a while, so generally
> upgrades can happen without recompiling applications. Of course, it
> does introduce the whole LD_LIBRARY_PATH issue ;).
>
> Brian
It looks as if LAM is built statically, but has ended up in a dynamic
library. This is on Darwin aka Mac OS X. If anyone can shed any
light on what's going on, I'd appreciate it.
LAM was built with all the defaults, and the endproduct seems to be
some .a and .la files. There are a few .dynlib's, but only for
totalview.
The module that uses them is a dynamically loaded file Rmpi.so, which
is a "bundle" in Darwin-speak. It is definitely not part of the
original R executable, having been built after it. It's loaded
dynamically. (Note it does not have the .dylib extension, which
indicates a "dynamic library." But the docs seem to indicate that
bundles are things that get loaded after program startup).
I've hunted through the Mac documents without finding anything
explicit one way or the other about putting static files into dynamic
ones. I've noticed that in place of the usual categorical statements
(e.g., you must compile PIC if you want a dynamic library) are only
ones about optimization (to get full benefits compile a particular
way). It is also possible the necessary files are coming out of the
.la files. Note that Mac has a libtool that is distinct from GNU
libtool, though both manage libraries. I'm not sure which is making
the .la files.
Rmpi.so has no references to external mpi libraries, and does have the
necessary symbols defined in the file (according to otool).
So it looks kind of as if I'm in the "LAM is a static library"
scenario you outlined above. But things seem to work. Rmpi was built
with 7.1.1 or earlier. When I try to run it in a 7.1.2beta
environment, everything seems to work. (Alternate possibility is that
my transition to 7.1.2beta is incomplete).
Even if you can't explain the preceding mess, perhaps someone here can
answer a simpler question: if I have a version mismatch, will I have
obvious failures? The scenario that worries me is that I might get
subtle problems that corrupt my results without obviously blowing up.
|
