On 2012-05-26 08:22:58 (+0200), Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
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 the java-1_5_0-gcj-compat package is installed.
The compiler gcj should always include it in normal 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-1.5.0.0/jre/lib/rt.jar but not libgcj.jar.
Is this a gcj error or should it require the compat package?
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: /usr/lib64/jvm/java-1.6.0-openjdk-1.6.0/jre/lib/rt.jar See: http://docs.oracle.com/javase/6/docs/technotes/tools/linux/jdkfiles.html
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 ... cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf