[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