Re: New LAM package

[Camm Maguire <camm@enhanced.com>]

Greetings!  Just thought I might take this opportunity to poll your
opinions on the structure of this package.  Here is my question:

 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.  Now that the
   libraries are shared, all the lam stuff is loaded into memory when
   lamd is running.  Linking to the merge library then loads in
   another copy when you run your program.  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?  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), 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.  

   What do you think?



-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah