Red Hat Bugzilla – Bug 233489
trouble to build pdftk
Last modified: 2007-11-30 17:11:59 EST
When I try to build pdftk for the devel branch; i will get the following error message: gcjh --classpath="." Gnu; Exception in thread "main" java.io.IOException: can't find class file java_local/security/Provider.class in java.net.URLClassLoader{urls=[file:/builddir/build/BUILD/pdftk-1.41/java_libs/gnu_local/j ava/security/provider/./,file:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/rt.jar], parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], pare nt=null}}} at gnu.classpath.tools.javah.Main.getClass(libgcj-tools.so.8rh) at gnu.classpath.tools.javah.ClassWrapper.linkSupers(libgcj-tools.so.8rh) at gnu.classpath.tools.javah.ClassWrapper.printFully(libgcj-tools.so.8rh) at gnu.classpath.tools.javah.CniIncludePrinter.printClass(libgcj-tools.so.8rh) at gnu.classpath.tools.javah.Main.writeHeaders(libgcj-tools.so.8rh) at gnu.classpath.tools.javah.Main.run(libgcj-tools.so.8rh) at gnu.classpath.tools.javah.GcjhMain.main(libgcj-tools.so.8rh) make[2]: *** [Gnu.h] Error 1 rm Gnu.class make[2]: Leaving directory `/builddir/build/BUILD/pdftk-1.41/java_libs/gnu_local/java/security/provider' make[1]: *** [libgcj_local] Error 2
I think the --classpath option should be ".:../../../..". That said, Rawhide pdftk shouldn't need gcjh to build: it should be able to BuildRequire system dependencies rather than bundling the dependencies under java_libs.
I filed a separate bug for the dependency issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233514
I looked at pdftk a little a week or two ago. It included some classpath security code... this seemed weird to me. Its use of gcjh worked with the old gcjh, but won't work any more. gcjh really needs to traverse the class hierarchy (both for miranda methods and also to properly handle bridge methods). So the approach pdftk takes to invoking gcjh no longer works, and can't really be made to work. Instead a package has to invoke gcjh in a "java-like" way. So eg when making a header for "p1.p2.Class", gcjh ought to be invoked from $basedir, not $basedir/p1/p2/ -- I hope this makes sense. If the target class(es) has a dependency on some other set of classes, these must be findable by gcjh using the class path.
I committed a patch to invoke gcjh in the new way and rebuilt this package in Rawhide.