RE: statically linked compile...

[Lumpkin, Buddy]

This probably isn't the best way to statically compile cfengine, but it worked 
fine for me 

Solaris 2.6
Berkeley DB.3.3
openssh installed under /usr/local/openssh
...

I just edited the configure script and changed every occurence of -lxx to the 
fully qualified path of the library that is being linked.

-ldb becomes /usr/local/BerkeleyDB.3.3/lib/libdb-3.3.a (substitute your version 
of course)
-lcrypto becomes /usr/local/openssl/lib/libcrypto.a
.. you get the idea
I also changed the line that links libpub.a from something like -L ../pub -lpub 
to ../pub/libpub.a.

I left the OS stuff dynamic since that will be on any OS.

Also, just for kicks I set my LDFLAGS:

LDFLAGS="/usr/local/BerkeleyDB.3.3/lib/libdb-3.3.a 
/usr/local/openssl/lib/libcrypto.a /usr/local/openssl/lib/libssl.a"
export LDFLAGS

And CPPFLAGS:

CPPFLAGS="-I/usr/local/BerkeleyDB.3.3/include -I/usr/local/openssl/include"
export CPPFLAGS


Here's the output of make compiling cfagent ...

gcc  -g -O2    /usr/local/BerkeleyDB.3.3/lib/libdb-3.3.a 
/usr/local/openssl/lib/libcrypto.a /usr/local/openssl/lib/libssl.a 
-L/usr/local/lib -o cfagent  cfagent.o do.o wrapper.o report.o client.o 
process.o ifconf.o image.o item.o item-ext.o item-file.o 2Dlist.o globals.o 
classes.o misc.o parse.o
edittools.o patches.o install.o link.o tidy.o filedir.o eval.o modes.o 
chflags.o locks.o mount.o macro.o filenames.o varstring.o wildcard.o cfparse.o 
comparray.o read.o checksums.o proto.o filters.o copy.o repository.o rotate.o 
errors.o cflex.o net.o df.o log.o encrypt.o popen.o popen_def.o
sensible.o acl.o dce_acl.o nameinfo.o strategies.o -ll 
/usr/local/BerkeleyDB.3.3/lib/libdb-3.3.a -lpthread 
/usr/local/openssl/lib/libcrypto.a /usr/local/openssl/lib/libssl.a -lnsl 
-lsocket -lm  -lelf -lsec ../pub/libpub.a


Comments are welcome :)

--Buddy


-----Original Message-----
From: Scott Walters [mailto:scott@PacketPushers.com]
Sent: Friday, December 28, 2001 7:31 AM
To: help-cfengine@gnu.org
Subject: Re: statically linked compile...



Andrew,

        I don't think you are alone in your predicament.  I am currently
trying to rollout cfengine 2 to a bunch of Sun machines running 2.5.1,
2.6, 2.7 and 8.  I'd like to have the functionality of both DB and SSL.

        I would really prefer that the cfengine 'package' be standalone
with no dependencies to other installed software.  This also alleviates
ongoing maintenance issues.  I am not concerned with the inefficiency of a
statically linked binary over a shared one.

        I am not an expert in programming or compiling, so getting things
static is a bit of a stretch.  If you could send me your notes I will try
things on the Solaris side.

        Another possible way to deal with this chicken/egg dilema, is to
have a 'bare-bones' cfengine install (without DB or SSL), and then have
cfengine install the necessary libraries, and then upgrade itself.  That
process, though feasible, seems unecessarily complicated (and prone to
error).  And the sunfreeware.com DB and SSL library packages do not put
things in /usr/local/lib, which leads to LD_LIBRARY_PATH issues, etc.  The
more parts, the more places things can break . . .

        Either way this issue should get resolved and documented because
I'd imagine it affects everyone that attempts to use cfengine.  If your
environment is so 'managable', that it is easy to get all the libraries
where they need to be, then how much help would cfengine be anyway? <wink>

        Let me know if you make progress with the static build.

scott


On Fri, 28 Dec 2001, Andrew Mayhew wrote:

> To be honest, I didn't need all the libraries statically linked, just things
> like BerkeleyDB and the Openssl libraries.  In other words, things that
> would not be installed in a plain vanilla install.  The heart of the matter,
> though, is that those 6.2 machines need to be reinstalled and brought up to
> spec.  If cfengine were statically linked, you could do some real low level
> os replacements (like upgrading from 6.2 to 7.2) without worrying about
> killing the library the process needed.
>
> Basically, it is one of these chicken and the egg kind of problems.  How do
> you get cfengine on machines that are already out on the network without any
> other management tools.  With the other part of the problem being that 1)
> all machines in production up to this point are hand crafted, and 2) you
> want to install as few bits a possible in order to be as sure as possible
> that you will not break something existing.
>
> As for being able to bring up a 6.2 machine to do the build, the reasources
> are not available for such things.  Time and money are against me.  Since I
> was attempting to lay down cfengine "real quick" to replace an ad-hoc
> process (software release from development to production), I didn't have
> time since I was told that I would be responsible for this hand off
> Wednesday night for a Thursday handoff.  Hardware wise- there is less than no
> money available to purchase.
>
> Thanks.  If anyone has any ideas on just statically linking the BerkeleyDB
> (libdb-3.3.so) and Openssl (libcrypto.so) libraries, that would be cool.
> Since this is hour 23 in the office my mind has stopped functioning at a
> high enough level to know if this is 1) feasible and 2) something I already
> know how to do.
>
> Thanks and apologies for the rambling.
> --Andy
>
> On Fri, Dec 28, 2001 at 08:24:14AM -0500, Andrews, Martin wrote:
> > What exactly is the failure? I tried a quick relink on my redhat 7.2 box but
> > could not find all the static libraries I needed (-lnss_nis). Are you sure
> > you have static versions of all the libraries cfengine uses?
> >
> > In general this sounds like a dangerous idea - much has changed between 6.x
> > and 7.x and taking code compiled from newer OSes is always likely to fail.
> > Can't you put together a quick 6.2 box (we were just selling off a bunch of
> > pentium pro PCs like the ones I use for linux builds for $50 a pop...)?
> >
> > Martin
> >
>
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine
>

-- 
Scott Walters
-PacketPusher


_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://mail.gnu.org/mailman/listinfo/help-cfengine