[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nonstandard lib location & LD_RUN_PATH

From: Brendan Strejcek
Subject: Re: Nonstandard lib location & LD_RUN_PATH
Date: Tue, 29 Nov 2005 10:36:16 -0600
User-agent: Mutt/1.5.6+20040818i

Martin, Jason H wrote:

> -static would work. The downside is that a totally static-linked
> binary is very large. The effect is multiplied when you consider that
> cfservd / cfrun / cfagent all would have their own statically linked
> copy of libc/openssl/berkeleydb. I am aiming to avoid that as disk
> space is an issue on some hosts.


Ah. Space is not an issue for me, but even if it were, I only have one
machine running cfservd, and clients only need cfexecd and cfagent.
Using shared libraries, cfexecd is 100 KB and cfagent is 508 KB.
Statically linked, cfexecd is 1745 KB and cfagent is 3145 KB. Also,
if you are using non-system copies of the OpenSSL and Berkeley DB lib
directories, you need to add that in as well (on an example system
of mine that brings the total to 3364 KB). That is still less than
1745 + 3145 = 4890, but not by much. And unless the libraries are
packaged along with the custom cfengine build, you have more objects
to distribute. Of course, the major con to static builds in my view is
that you multiply the number of packages that you need to upgrade when
the next OpenSSL security problem comes up, since just upgrading the
system OpenSSl is not enough. On the other hand, a system OpenSSL update
could in theory adversely affect the functioning of cfengine, which
is a pretty core system component, so it is kind of nice to have it
partitioned from the rest of the system...



Senior System Administrator
The University of Chicago
Department of Computer Science

reply via email to

[Prev in Thread] Current Thread [Next in Thread]