Re: New LAM package
>> Camm Maguire <camm@enhanced.com> writes:
> In the past, we had the 5 (static) libs shipped with lam
> installed under /usr/lib/lam/lib, and a "merge" lib built, with
> a link under /usr/lib, so that one could compile as simply as
> cc -I /usr/include/mpi *.c -o foo -lmpi.
ok.
> Now that the libraries are shared, all the lam stuff is loaded
> into memory when lamd is running.
$ ldd /usr/bin/lamd
libargs.so.1 => /usr/lib/lam/lib/libargs.so.1 (0x40011000)
libtstdio.so.1 => /usr/lib/lam/lib/libtstdio.so.1 (0x40017000)
libtrillium.so.1 => /usr/lib/lam/lib/libtrillium.so.1 (0x4001f000)
libt.so.1 => /usr/lib/lam/lib/libt.so.1 (0x40028000)
libmpi.so.1 => /usr/lib/lam/lib/libmpi.so.1 (0x4003c000)
libc.so.6 => /lib/libc.so.6 (0x40083000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
so, after booting lam, each and every library is loaded.
> Linking to the merge library then loads in another copy when you
> run your program.
"another copy"? which one is the merge library? From debian/rules, I
guess it's liblam, but that isn't loaded by lamd...
> Sort of defeating part of the purpose for a shared library.
> (There is still a benefit when more than one mpi app is running,
> of course.) Should I make all the lam1-runtime binaries link
> against the merge library, and eliminate the sub libraries, or
> should we eliminate the merge library, and force everyone to use
> hcc or a more complicated cc command line?
Does it make a difference in terms of memory footprint for the
utilities? I've always used cc with -lmpi and the appropiate
libraries, and normally don't use hcc (except when trying to explain
some people here what to do to compile an MPI program)
> I haven't used the new mpicc with this package, but it may end
> up providing the implementation transparency (i.e. we want code
> to compile just as well with lam as with mpich)
I've found some packages (CACTUS in particular) that use MPI, and
IIRC, they do expect mpicc to be available. At least in terms of
compatibility with the rest of the MPI community, this is good.
> as we had achieved with the alternative and the merge library.
> Of course, combining the libs into one for all apps has clear
> advantages too, its just a (perhaps) significant change to the
> upstream package.
MPI is lots more standard than, say, PVM. I guess we should take a
look at the MPI Standard, and try to preserve compatibility with
that, which means, use mpicc, AFAIC recall. I don't have the
standard here with me.
Marcelo
Reply to: