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

[Florian Forster]

Hi Peter,

On Thu, May 14, 2009 at 05:07:34PM +1000, Peter Bray wrote:
> 
>    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.

I've added an appropriate output to the summary of the configure script,
thanks for the pointer :)

> 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

I agree fully that this solution is not optimal, but unfortunately it's
the only one I could come up with. It'd be great to have a libjvm-config
or jni-config script or even a pkg-config file, but as far as I know
(and everyone I asked so far) there is no such script/file.

> 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.

The problem is that the directory structure depends on which Java you're
using. libjdk uses a similar but not identical structure (I think some
architecture names differ), gcj uses something completely different (and
vastly more UNIX-like), etc..

> 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.

This sounds much more interesting, because it will work with archi-
tectures we haven't tested ourselves. The downside I'm seeing is that
figuring out how to use that option is not really easier than using the
existing JAVA_*FLAGS: To use the option, the user needs to know what the
problem is and in which directory the appropriate libjvm.so resides.
Once you're that far, simply specifying the directory on the command
line is probably easier than figuring out what to tell grep..

Of course, feel free to submit a patch.. We don't have to decide for one
solution or another, as far as I can see they can coexist without
problems..

> 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.

Maybe tips like this are easier to find on the wiki page. Could you
maybe add your findings / suggestions to
 <http://collectd.org/wiki/index.php/Plugin:Java>?
That'd be great :)

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090518/bab0f510/attachment.pgp