Distributing Linux Software

[gaf-mNDKBlG2WHs at public.gmane.org (Jerry Feldman)]

This is true. Our product is huge, and as I mention we not only ship a
very larger number of shared objects (eg over 300 in our core product)
not to include ancillary libraries that are built separately. But, the
reason for this is that our architecture allows for many of the
libraries to be used based upon attributes. Additionally, customers can
write their own extensions. So, let's say I have a financial instrument
that is based on the stochastic process method, the SPM module would be
dynamically loaded (via dlopen/dlsym) at run time. So, a customer must
determine what features are being used. Some of this is set up when we
ship the product, some set up by the installation, and some by the user.
And, as I said our product is huge, and typically takes hours to run
with many computers in parallel. (Basically, analyze a financial
portfolio using a simulation of a number of years along with pricing
assumptions).
As you mention, there is no right and wrong way. Every platform has its
own issues.

On 03/19/2010 02:02 PM, Richard Pieri wrote:
>
> Indeed.  There is no One True Correct Answer that will Solve All of You=
r Release Engineering Problems.  If you ship shared libraries with your e=
xecutables then you have one set of problems.  If you ship the whole thin=
g as a single static executable then you have a different set of problems=
=2E  Choose your battles.  I for one would prefer to avoid fighting battl=
es over library conflicts and dependencies so my preference is for static=
 executables.
>
> Regardless of which path you choose, make sure you thoroughly document =
your build platforms.  Worse than a customer having a problem is you bein=
g unable to run your own code because someone ran "apt-get dist-upgrade" =
on your build box behind your back.
>  =20

--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846