[Top][All Lists]

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

RE: Solaris 2.6 cfexecd 2.1.13 problem

Subject: RE: Solaris 2.6 cfexecd 2.1.13 problem
Date: Wed, 23 Feb 2005 16:11:08 -0700

This is info on my cfengine build for solaris if it helps:
I can also send binaries if requested for testing.

SunOS <hostname> 5.8 Generic_108528-15 sun4u sparc SUNW,UltraAX-i2
cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15

# berkeleydb/db-4.3.21
export CC=cc
export CFLAGS="-xO4 -xCC -w -Bstatic -dn"
../dist/configure --enable-smallbuild --disable-shared
# openssl-0.9.7c
CC=cc CFLAGS="-xO5" ./config no-threads zlib no-shared 
-I/home/rxanders/zlib-1.2.1/objtree/"`uname -s`-`uname -r`-`uname -m`"
# cfengine-2.1.11
# One time - Compiler always uses dynamic *.so over static *.a libs.
#            Create dir ssl-db and populate with static *.a libs
#            for ssl/db so we don't have to distribute them also.
#            OS dynamic libs needed because of cfengine code.
#            This also allows same binaries on 5.7/5.8 also.
#            After compiling, verify OS libs are only ones dynamic:
#            ldd src/cfrun
#      =>        /usr/lib/
#      =>     /usr/lib/
#      =>   /usr/lib/
#      =>   /usr/lib/
#      =>   /usr/lib/
#      =>     /usr/lib/
#      =>    /usr/lib/
#      =>    /usr/lib/
#               /usr/platform/SUNW,UltraAX-i2/lib/
# Commands used to populate ./ssl-db/lib ./ssl-db/include
# cd /apsrc/systems/cfengine/cfengine-2.1.11-SunOS-sparc/ssl-db/lib
# cp /apsrc/systems/berkeleydb/db-4.3.21.NC-SunOS-V5.8-sparc/build_unix/libdb-4.
3.a .
# ln -s libdb-4.3.a libdb.a

# cd /apsrc/systems/cfengine/cfengine-2.1.11-SunOS-sparc/ssl-db/lib
# cp /apsrc/systems/openssl/openssl-0.9.7c/objtree/SunOS-5.8-sun4u/lib*.a .

# cd /apsrc/systems/cfengine/cfengine-2.1.11-SunOS-sparc/ssl-db/include
# cp /apsrc/systems/berkeleydb/db-4.3.21.NC-SunOS-V5.8-sparc/build_unix/*.h .
# cp -pr /apsrc/systems/openssl/openssl-0.9.7c/objtree/SunOS-5.8-sun4u/include/o
penssl .
# Change to build directory
cd /apsrc/systems/cfengine/cfengine-2.1.11-SunOS-sparc
# Define additional libraries that are needed
export LIBS="-lnsl"
# Define the system compiler
export CC=cc
# -xO4                  Turn on the compiler code optimizer
# -xCC                  Accept C++ style comments
# -w                    Suppress compiler warning messages
# -DHAVE_GETNETGRENT=1  Configure fails to detect system *netgrent
#                       <netdb.h> functions so we have to tell it.
# Use Sun yacc versus bison
export YACC="/usr/ccs/bin/yacc"
# Run configure with openssl and berkeleydb defined

-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf Of
Mark Burgess
Sent: Wednesday, February 23, 2005 12:25 PM
To: Adam M. Dunn
Cc: Cfengine List Help Mailing
Subject: Re: Solaris 2.6 cfexecd 2.1.13 problem

On Wed, 2005-02-23 at 12:22 -0600, Adam M. Dunn wrote:
> I've been having a very similar problem throughout the last few versions
> of cfengine.  I don't know if it's identical to yours, but I've been
> getting segfaults non the less with 3.x compilers, and now 2.95 compilers 
> also on some versions of Solaris.  It's becoming very annoying. 
> Back when I was using 2.1.11, I couldn't get it to run in daemon mode
> without seqfaulting when I compiled using gcc 3.x.  My solution then was
> to use 2.95 which solved it.  When I upgraded to 2.1.13, I couldn't even
> get it to compile at all on a Solaris 5.8 or above with gcc 3.x.  I get 
> compile errors.  Gcc 2.95 compiled fine, but it started having that
> seqfault problem on some machines too.  However, compiliations I did on
> Solaris 2.6 with gcc 2.95 don't seem to have any problems, so I've been
> using those binaries on all our versions of Solaris with no problems yet.
> Doing work arounds always scares me.  The thing here that bothers me is
> when we retire our 2.6 boxes I either have to keep one of these old 
> machines around just for compiling new versions of cfengine, or I'm out of
> luck!
> Mark looked at this problem with me once before and we could never
> pinpoint it, but I think it's a pretty serious issue that needs
> investigating by someone.

I have never been able to reproduce this problem. I am seeing some odd
behaviour in cfenvd lately, but that's about it. I have not had a
cfservd of cfagent crash for a long long time.

I wish I knew what this was about.


Help-cfengine mailing list

reply via email to

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