Again, thanks to everybody for really timely and high-quality feedback! On 15 October 2008 at 18:18, Jeff Squyres wrote: | That being said, this kinda breaks the whole model of: | | shell$ gcc myapp.c # produces dynamic linked executable | shell$ gcc myapp.c -static # produces static linked executable
That definitely stinks. In Debian's quest for "Ueber"-perfection, that would lead us to provide two _separate_ package for OMPI in static and shared mode. But given the issue ... I think it would be overkill by a wide margin. | Yes; just configuring OMPI with --enable static will provide all the | Right stuff in terms of the libraries. OMPI defaults to "--enable- | shared --disable-static", so you probably want to specify "--disable- | shared --enable-static" to flip the defaults around. I don't No -- we like --enable-shared as a default. Just like you detailed in your previous email, this _is_ a sane default. | Indeed, if you build twice, once with --enable-static + --disable- | shared and then again with --disable-static + --enable-shared, then | you'll get a libmpi.a with all plugins slurped, and a libmpi.so with a | $pkglibdir full of all the plugins. If these are both installed under We could do that instead, but it requires rejigging of the package build process. I for one don't have the energy for it. Maybe Manuel's idea of a README about what one has to tweak to build a local static variant is the best bet? I usually set my goals as -- providing the best solution (subject to some reasonableness constraints) -- do not deviate too far from upstream Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
