On 2012-05-26 08:22:58 (+0200), Stefan Seyfried <stefan.seyfried(a)googlemail.com>
Am 24.05.2012 17:01, schrieb Michael Matz:
> But the strange thing is why pdftk needs to
explicitely mention that
> libgcj.jar anywhere.
I tried to omit it and it actually builds, but only if
java-1_5_0-gcj-compat package is installed.
> The compiler gcj should always include it in
> compilations automatically (like gcc also adds the right path to libgcc).
From the error I got wihtout the compat package it
looks like the
compliler only includes
/usr/lib64/jvm/java-1.5.0-gcj-4.7-188.8.131.52/jre/lib/rt.jar but not libgcj.jar.
Is this a gcj error or should it require the compat
Where libgcj.jar is the equivalent of libgcc.so, rt.jar is sort
of the equivalent of libstdc++ as it includes the core classes
of the JDK, also with OpenJDK and the Oracle JVM:
> I know you said pdftk doesn't build when it
isn't mentioned, but
> _that's_ what should be investigated. Could be either gcj doesn't add
> although it should, or that pdftk isn't using gcj properly, or the like.
pdftk's build system is probably suboptimal.
If it pulls in libgcj.jar, I would think so too.
Any specific reason they're building "hardcoded" against gcj
instead of just plain java (e.g. OpenJDK) ? That's really odd, I
don't believe I've ever seen something like that.
Sure, you can make native binaries, but they still pull in and
use a JVM (Java Virtual Machine) internally if I remember
correctly (the one that's in libgcj.so).
Binaries built and/or run with gcj have a much faster startup
time but they run slower than with, say, OpenJDK.
And the Java application startup time is almost entirely caused
by the allocation of the heap.
If you start it with a small heap, you'll notice the difference:
java -Xmx8m ...
-o) Pascal Bleser
-- we haz green
-- we haz conf