[collectd] Observations on compiling collected-4.7.0 on Solaris 10 Update 6

Peter Bray pdb_ml at yahoo.com.au
Thu May 14 09:07:34 CEST 2009


Hi All,

   I just thought I'd document a few observations from building collectd 
4.7.0 for Solaris 10 Update 6 with GCC-4.1.2 on both SPARC & X86 in both 
  32-bit and 64-bit mode.

Perl Support:

Configuration:
   Libraries:
     libperl . . . . . . . yes (version 5.10.0)
   Bindings:
     perl  . . . . . . . . yes
   Modules:
     perl  . . . . . . . . no

   This surprised me at first, but looking back through the configure 
output and config.log, it mentions that perl does not have 'ithreads' 
support. Neither my locally build Perl 5.10.0 or the Solaris provided 
Perl 5.8.4 have 'ithreads' support, so you can't embed the perl 
interpreter into collectd :-( Maybe this requirement should be mentioned 
in the configuration summary or the README.

Java Support:

   The README is very good here but I just thought I mention a little 
gotcha in the configure.in script for those compiling on 64-bit 
platforms (a must for swap support). The configure.in code for looking 
for libjvm.so is as follows:

AC_MSG_CHECKING([for libjvm.so])
TMPDIR=`find -L "$with_java_home" -name libjvm.so -exec 'dirname' '{}' 
';' | head -n 1`
if test "x$TMPDIR" != "x"
then
     AC_MSG_RESULT([found in $TMPDIR])
     JAVA_LDFLAGS="$JAVA_LDFLAGS -L$TMPDIR"
else
     AC_MSG_RESULT([not found])
fi

Looking at output of the find command on a system with both 32-bit and 
64-bit Java 6 installed, I got the following:

[root at tabula] # find -L /usr/jdk/instances/jdk1.6.0  -name libjvm.so 
-exec 'dirname' '{}' ';'
/usr/jdk/instances/jdk1.6.0/jre/lib/i386/client
/usr/jdk/instances/jdk1.6.0/jre/lib/i386
/usr/jdk/instances/jdk1.6.0/jre/lib/i386/server
/usr/jdk/instances/jdk1.6.0/jre/lib/amd64/server

This is not a big problem if I'm compiling in 32-bit as the "head -1"
picks the client 32-bit library, but its a bit dependent on the order of 
the output of find.

It would be nice if we could map the compiler output (32-bit or 64-bit) 
to the JRE lib names (i386/amd64/sparc/sparcv9) and select on that basis.

I wonder if adding a configure option to determine the preferred jvm 
library could be achieved with the quick & dirty use of a grep pattern. 
Say --preferred-libjvm=<pattern> (which say defaults to "." or something 
sensible), so that a user-specified pattern such a 
"--preferred-libjvm=amd64/server" inserts a "grep" command between the 
"find" and "head", this could make the outcome a little more deterministic.

Have said that, the README suggested solution as shown below works fine:

Assuming the use of --with-java=/usr/jdk/instances/jdk1.6.0 the 
following before the configure invocation will allow 64-bit builds.

X86_64	

JAVA_LDFLAGS="-L/usr/jdk/instances/jdk1.6.0/jre/lib/amd64/server"

SPARC64

JAVA_LDFLAGS="-L/usr/jdk/instances/jdk1.6.0/jre/lib/sparcv9/server"


   I hope this posting will help others looking at collectd for the 
first  time. The "contrib/collections3" web interface is very nice, I 
still have a TO-DO on how to integrate into my environment.

Regards,

Peter Bray
Sydney, Australia



More information about the collectd mailing list