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 make -------------------------------------------------------- # 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 # libsocket.so.1 => /usr/lib/libsocket.so.1 # libm.so.1 => /usr/lib/libm.so.1 # libnsl.so.1 => /usr/lib/libnsl.so.1 # libelf.so.1 => /usr/lib/libelf.so.1 # libsec.so.1 => /usr/lib/libsec.so.1 # libc.so.1 => /usr/lib/libc.so.1 # libdl.so.1 => /usr/lib/libdl.so.1 # libmp.so.2 => /usr/lib/libmp.so.2 # /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 # #--------------------------------------------------------------- # 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. # export CFLAGS="-xO4 -xCC -w -DHAVE_GETNETGRENT=1" # # Use Sun yacc versus bison export YACC="/usr/ccs/bin/yacc" # # Run configure with openssl and berkeleydb defined # ./configure --with-berkeleydb="/apsrc/systems/cfengine/cfengine-2.1.11-SunOS-sparc/ssl-db" --with-openssl="/apsrc/systems/cfengine/cfengine-2.1.11-SunOS-sparc/ssl-db" make -------------------------------------------------------- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. M _______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine _______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
