[torquedev] Re: [torqueusers] Fwd: [O-MPI users] OpenMPI 1.0.1 with Torque 2.0

[Jeff Squyres]

(taking the liberty of replying to torquedev...)

On Jan 3, 2006, at 3:35 PM, Garrick Staples wrote:

>> Is there any way that Torque can produce shared libraries?  This
>> would solve our problem nicely.  :-)
>
> I would LOVE to build shared libraries.  I'm sick of rebuilding  
> maui and
> perl-PBS everytime I make a tiny change in any of the client libs.

Excellent.  :-)

> TORQUE's autotools setup is pretty messed up right now so I don't want
> to make any deep changes.  But I plan to rewrite configure.in in the
> near future.

Be sure to name it configure.ac -- Autoconf changed the default  
"preferred" name to configure.ac a while ago (configure.in will still  
work fine, but the AC docs now encourage the use of configure.ac to  
distinguish it from other *.in files).  :-)

> TORQUE builds 6 static archives (7 if you cound pbs_sched.a), 5 of  
> which
> have impossibly generic names.  I figure we could either make
> "libtorque-foo.so" libnames, or stuff everything into 1  
> "libtorque.so".
>
> We need to be very careful about this because 1) TORQUE runs on a  
> lot of
> platforms, 2) we do make regular changes to the client libs, and 3)  
> more
> and more 3rd party stuff (like open-mpi) builds against TORQUE.

You might want to look into Automake and Libtool.  Libtool's express  
purpose is to be able to build shared libraries transparently on  
oodles of combinations of compilers / platforms.  We've found the  
Libtool team to be *extremely* responsive to helping solve problems,  
fix bugs, issue new releases when necessary, etc.  I can't speak  
highly enough of them!

Plus, Libtool is fully integrated into Automake.  So if you use the  
full trifecta (Autoconf + Automake + Libtool), the use of Libtool and  
building shared libraries is totally transparent to your  
Makefile.am's.  This is what we do in both LAM and Open MPI, for  
example -- we never mention Libtool at all in our Makefile.am files;  
we just say "build this library" and the AM+LT integration figures  
out the Right Stuff and does it.  Specifically -- AM by itself knows  
how to build static libraries.  Activating the AM+LT integration  
enables building static and/or shared libraries.  The AM docs are  
effectively a tutorial and show some examples on how to activate the  
Libtool integration.

For the most part, we (LAM / Open MPI) worry about other issues;  
shared libraries are a solved issue because of Libtool (indeed, our  
default is to build shared libraries and DSOs, but Libtool  
automatically adds some --switches to configure that enable the user  
to specify building shared, static, or both).

The one caveat here is that you really need to use recent versions of  
AC, AM, and LT.  For whatever reason, Linux distros are *really* slow  
to update the included versions.  We explicitly require all LAM and  
Open MPI developers to have recent versions available (e.g., AC 2.59,  
AM 1.9.6, and LT 1.5.22).  All are available from ftp://ftp.gnu.org/ 
gnu/.  See the Open MPI HACKING file for more details:

	http://svn.open-mpi.org/svn/ompi/trunk/HACKING

This is just my opinion, of course.  Build systems can be a highly  
religious issue.  :-)

> Do you know if other PBS implementations (I guess that means PBS Pro)
> have built a shared lib?  If so, what libname(s) were used?   
> Maintaining
> binary compatibility would be nice, but I doubt that will happen.

I unfortunately don't know -- we currently -lpbs for both PBS Pro,  
Open PBS, and Torque and that grabs all the TM stuff that we need.

--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/