[Pkg-openmpi-maintainers] Bug#502232: Bug#502232: libopenmpi-dev: No static libraries in the package

[Manuel Prinz]

Hi Jeff,

thanks for taking the time to explain the issue!

Am Mittwoch, den 15.10.2008, 16:13 -0400 schrieb Jeff Squyres:
> Static libraries are definitely a Good Thing in some scenarios.  We  
> have a few features in this arena, which we consider separately:
> 
> - building libmpi (and friends) as .a instead of .so
> - slurping all the plugins into libmpi (and friends) instead of  
> creating them as standalone DLLs
> - disabling dlopen altogether
> 
> When someone says "building static", they usually mean enabling all 3  
> of those options.

I think this would be our use case.

> Building statically is certainly an option; I confess to not knowing  
> enough about deb's to know if you can embed conditional logic in there  
> to build dynamically if the user doesn't specify anything, or enable  
> some/all of the 3 above features if requested.  E.g., RPM's have a  
> kinda kludgey way to pass in build options.

We have ways to provide some magic, or performing multiple builds in a
row which creates just one Debian package. This is a technical
discussion we maintainers have to have.

> However, keep in mind that compiling statically with OpenFabrics adds  
> an unfortunate new dimension of complexity in terms of creating fully- 
> static MPI libraries and applications:
> 
>      http://www.open-mpi.org/faq/?category=openfabrics#ib-static-mpi- 
> apps

True. The libibverbs issue seems to only add complexity for the user, as
there's just static versions of OpenMPI and libibverbs needed. We just
need to provide those, the compiling and linking of the application is
done by an MPI user. Did I get that right?

We may think about some script or alike that does the necessary work for
the user, though, and include that in the package. This would need some
testing and time. Gary, would just providing be static libraries be OK?
I guess we can do that without too much effort.

As I see it, the options are:

     1. Just build static libs. May need two build cycles, but not too
        hard to do. (Already done that.) This has the nice effect that
        no extra action on the user side is necessary. 
     2. Define some value that can be passed to the build process, that
        triggers the build of static libs. We can document it in
        README.Debian and all users need to do is a dpkg-buildpackage
        run. GROMACS did this for quite some time, for example, and I
        always found that convenient enough. 
     3. Just provide dynamic libraries. Easiest to maintain, extra
        effort for the user. IMHO not acceptable if there is no good
        technical argument against it, as seems to be the case here.

Opinions?

Best regards
Manuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-openmpi-maintainers/attachments/20081015/023921c8/attachment-0002.pgp