help-cfengine
[Top][All Lists]
Advanced

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

RE: Nonstandard lib location & LD_RUN_PATH


From: Martin, Jason H
Subject: RE: Nonstandard lib location & LD_RUN_PATH
Date: Tue, 29 Nov 2005 08:13:31 -0800

-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.

Thank you,
-Jason Martin

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Brendan Strejcek
> Sent: Tuesday, November 29, 2005 6:12 AM
> To: address@hidden
> Subject: Re: Nonstandard lib location & LD_RUN_PATH
> 
> 
> Another solution is static linking.
> 
> To end up with static binaries, run:
> 
>     LDFLAGS=-static; export LDFLAGS
> 
> prior to "configure". Not sure how cross-platform that is...
> 
> Best,
> Brendan
> 
> --
> Senior System Administrator
> The University of Chicago
> Department of Computer Science
> 
> http://www.cs.uchicago.edu/people/brendan
> 
> http://people.cs.uchicago.edu/~brendan
> 
> 
> Jason Martin wrote:
> 
> > LD_LIBRARY_PATH only affects runtime; since I can't set 
> that value on 
> > all the clients, I instead need to have the binary look in 
> the correct 
> > location inherently.
> > 
> > -Jason Martin
> > 
> > On Mon, Nov 28, 2005 at 08:17:32PM -0800, Brian C. Hill wrote:
> > >   LD_RUN_PATH works for at least both Linux and SunOS 5 
> (Solaris 2), 
> > > since -R<path> isn't a Linux ld directive.
> > > 
> > > Brian 
> > > 
> ====================================================================
> > > ==
> > > On Mon, Nov 28, 2005 at 05:01:38PM -0800, David Masterson wrote:
> > > > It would seem that the most crossplatform standard way 
> would be to 
> > > > set LD_LIBRARY_PATH in configure.ac during the processing to 
> > > > search for the BerkeleyDB library.
> > > > --
> > > > David Masterson
> > > > VMware, Inc.
> > > > Palo Alto, CA
> > > 




reply via email to

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