i've made some changes to the CVS which i think will fix the gstat problems. can you try it against CVS when you get a chance?
there is a test for the pthread(s) library in configure.in which should automagically append -lpthread to the LDFLAGS. is it not doing that on Tru64? -matt Today, Steven Wagner wrote forth saying... > I don't gknow. As I've stated on both ganglia lists, gstat to me is like > the promotional material that comes with my Amazon.com orders - it's nice > to know it's there, I look it over and never use any of it, and end up > throwing it out if it gives me any problems. > > I tossed "-lpthread" into the LDFLAGS for the other directories and that > cleared up the linking issues for everything but gstat. > > I run it without gmond, it dumps core. (core available on request) > > I run it with gmond running, I get this: > > gexec_cluster() XML_ParseBuffer() error at line 31: > not well-formed > > Unable to get hostlist from 127.0.0.1 8649! > > ---- > > Something tells me that gstat is having trouble parsing gmond output using > the new and improved DTD. (it *is* making the connection and gmond says > it's transmitting the XML dump OK) > > Once again, I never use it. So I don't know if it even works on other > platforms. > > Hmm, I should probably put something into autoconf to check for -lpthread ... > > matt massie wrote: > > so i just added your miracle osf.c to the CVS. what happens with gstat to > > make it gchoke? > > > > -matt > > > > Yesterday, Steven Wagner wrote forth saying... > > > > > >><GANGLIA_XML VERSION="2.5.0" SOURCE="gmond"> > >><CLUSTER NAME="unspecified" OWNER="unspecified" LATLONG="unspecified" > >>LOCALTIME="1029973784"> > >><HOST NAME="mauna" IP="10.10.77.125" LOCATION="unspecified" > >>REPORTED="1029973780" TN="4" TMAX="20" DMAX="0" GMOND_STARTED="1029973763"> > >><METRIC NAME="cpu_num" VAL="4" TYPE="uint16" UNITS="" TN="20" TMAX="1200" > >>DMAX="0" SLOPE="zero" SOURCE="gmond"/> > >><METRIC NAME="machine_type" VAL="alpha" TYPE="string" UNITS="" TN="20" > >>TMAX="1200" DMAX="0" SLOPE="zero" SOURCE="gmond"/> > >><METRIC NAME="gexec" VAL="OFF" TYPE="string" UNITS="" TN="20" TMAX="300" > >>DMAX="0" SLOPE="zero" SOURCE="gmond"/> > >><METRIC NAME="sys_clock" VAL="1029973763" TYPE="timestamp" UNITS="s" > >>TN="20" TMAX="1200" DMAX="0" SLOPE="zero" SOURCE="gmond"/> > >><METRIC NAME="mtu" VAL="1500" TYPE="uint32" UNITS="B" TN="20" TMAX="1200" > >>DMAX="0" SLOPE="zero" SOURCE="gmond"/> > >><METRIC NAME="os_name" VAL="OSF1" TYPE="string" UNITS="" TN="20" > >>TMAX="1200" DMAX="0" SLOPE="zero" SOURCE="gmond"/> > >><METRIC NAME="os_release" VAL="V5.1" TYPE="string" UNITS="" TN="20" > >>TMAX="1200" DMAX="0" SLOPE="zero" SOURCE="gmond"/> > >></HOST> > >></CLUSTER> > >></GANGLIA_XML> > >> > >>Not too many metrics to start with, but they all work. Ran gmond with very > >>low expectations, and *bam.* It auto-detects the multicast interface and > >>starts sending out packets (and receiving them). And as you can see the > >>XML dump bit works too. > >> > >>Attached is a working osf.c with mostly dummy values (but it's enough to > >>get it compiled so you can start coding metrics with it). Note that the > >>metrics above are all determined algorithmically (although I'm going to > >>change the os_name/release ones to use utsname instead of sysinfo calls). > >> > >>Found ways to get a pretty large subset of the Solaris data in Tru64 just > >>now, too. > >> > >>Compiled using: > >> > >>Monday afternoon CVS checkout. > >>GNU m4 1.4 > >>GNU autoconf 2.53 > >>GNU automake 1.6.3 > >>GNU libtool 1.4.2 > >>GNU gcc 2.95.3 > >> > >>P.S. gstat doesn't work. :) > >> > > > > > >
