Distributing Linux Software

[Jerry Feldman]

On my previous post, I mentioned that we bundled everything. We provide
a large number of shared libraries, partially because our product
dynamically loads its own libraries and would be huge if everything were
static.

Generally, if code is built on a certain release, it should not be run
on an older release, even if it is statically linked. While much of the
time, code built on a certain distro and statically linked can run on an
older distro, you are looking at trouble.

But, you are never guaranteed portability. let's take the kind of
extreme case, where one or more system calls were changed. The C runtime
library provided as wrapper to a system call, but if you build on the
later version, then your code might crash on an older version.

Another downside of using statically liked libraries is the size of the
executable. In today's huge memory, it is not so much of an issue.
Another downside is that your code will not benefit from bugs in
dependent libraries.

Today, with our package managers help to establish dependencies, such as
what versions of glibc or libstdc++ (or all dependent libraries). While
I would prefer to build a product using shared objects, that product is
subject to the issues you do describe below.

On 03/19/2010 12:36 PM, Richard Pieri wrote:
> On Mar 19, 2010, at 11:56 AM, Tim Callaghan wrote:
>  =20
>> I'm trying to get a better understanding of how other companies
>> distribute their Linux shared libraries.  My company plans on
>> supporting as many Linux versions/distros as possible.
>>    =20
> The simple answer is: don't use shared libraries.  Three key reasons:
>
> The first reason is portability.  If everything you need is statically =
linked to your executable then there are no external dependencies.  Your =
code should run everywhere.
>
> The second reason is support.  If you statically link everything then y=
ou don't have the support nightmare of customers either not having the li=
braries you need or, worse, having outdated libraries that you can't use =
but that he needs for some other application.
>
> The third reason is security.  If you statically link the libraries you=
 need then you won't (hopefully) have to deal with trojan libraries loade=
d via LD_LIBRARY_PATH.
>
> Your issues with OS versions is tangential to reason 2.  Code linked to=
 a particular version of the C library (glibc on Linux) will not run agai=
nst an older version of the C library.  Ubuntu 9.10 has a newer version o=
f glibc than 9.04 or CentOS 5.4; therefore, code linked to 9.10's glibc w=
on't run on 9.04 or CentOS 5.4.
>
> Welcome to the "joys" of release engineering.
>
>  =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