From: John Valdes <address@hidden>
Date: Mon Oct 14, 2002 01:32:11 PM US/Central
To: Bryan Ramirez <address@hidden>
Subject: Re: cfengine on OS X
On Wednesday, October 9, 2002, at 02:43 PM, John Valdes wrote:
On Wed, Oct 09, 2002 at 01:16:14PM -0500, Bryan Ramirez wrote:
Here is a sample of what I tried to run with the above environment
variables set as shown.
./cfagent -f cfagent.conf
bus error
[...]
Ha! All of these use the -f or --file option. When I use this with
cfagent 2.0.4 or 2.0.5pre, I get a bus error too!
prompt% env CFINPUTS=$HOME/cfengine ./cfagent -v -q -f cfagent.conf
Bus error
[...]
Looks like you've found a bug. :)
I found the problem. As I mentioned, cfengine includes it's own copy
of getopt (the GNU version). However, it appears that at build time,
cfagent and related commands are finding the system's copy of getopt,
or to be more exact, they system's copy of the "optarg" global used by
getopt, before it's own copy. cfagent itself actually uses
"getopt_long" which the system doesn't provide, so cfagent properly
links to to it's own copy of the getopt_long function, but getopt_long
is using it's internal "optarg" while cfagent is using the system
optarg. The result that the system optarg is never initialized by
getopt_long, so whenever cfagent tries to dereference it (whenever it
parses options that take arguments, so as the "-f" option), it
generates a bus error.
This fix is to be sure that cfagent links against it's own getopt
library before the systems. The link command used for cfagent in
2.0.5pre on OS X reads:
gcc -g -O2 -Wreturn-type -Wmissing-prototypes -Wuninitialized -g -O2
-I/usr/local/include -L/usr/local/lib -L/usr/lib -Xlinker -m -o
cfagent cfagent.o init.o do.o wrapper.o report.o client.o ip.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 functions.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 crypto.o popen.o
popen_def.o sensible.o acl.o dce_acl.o nameinfo.o strategies.o -lfl
-ldb -lcrypto -lpthread -lm -L../pub -lpub
In most Unix, including OS X, getopt is in libc, so the above should
work since -lc will be added to the end of the list of library given
on the command line. However, for whatever reason, OS X bundled the
"pthread" library into libc, and consequently, libpthread is actually
a symbolic link to libc (or "libSystem" as OS X calles it):
osx% ls -lF /usr/lib/libpthread.dylib
lrwxr-xr-x 1 root wheel 15 Sep 28 13:01 /usr/lib/libpthread.dylib@
-> libSystem.dylib
As a result, the "optarg" that's in libc (and hence libpthread) is
being found before cfengine's optarg that's in ../pub/libpub.a. The
fix, then, is to be sure that "-lpub" is listed before the other
libraries on the link command line. The attached patch to the
toplevel "configure.ac" takes care of this. Apply the patch, run
"autoconf", then proceed with the build as usual: "configure", "make",
etc. The "make" will actually rerun "configure" because of the change
the patch makes (I'm not familiar enough with how autoconf works, so
I'm not sure how to properly rebuild all the configure files before
the configure/make steps to satisfy the dependencies which are
triggering this second configure; the second configure does no harm,
however). After the build completes, you should find that "cfagent -f
..." now works. :)
John
cfengine-getopt.patch