Hide Forgot
pdftk bundles sources from GCJ, which it builds into the pdftk binary. Instead, it should dynamically link to the system-installed libgcj. Ideally the same would be done for the iText dependency, but this is more difficult because iText does not provide GCJ libraries that use the old-style GCJ ABI. Since pdftk uses CNI, and CNI relies on the old-style ABI the short-term solution would be for iText to provide an old-ABI library alongside its BC-ABI shared-object. The long term solution is to make CNI work with the BC ABI.
Thank you for your request. Unfortunateley, I have some trouble to build a patch version of pdftk on mock (FC7). Becouse it seems, you have a good knewledge about the gcj stuff, I have uploaded the source rpm and the build log on http://www.herr-schmitt.de/pub/pdftk/ I hope you can give me any hint to solve the problem. Best Regards: Jochen Schmitt
See Comment #1 on this bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233489 (We can continue discussion of the gcjh problem there, and use this bug report for discussion of using system libraries.)
I talked with Andrew Haley about this. He suggests building iText with -fno-indirect-classes as a temporary workaround until CNI supports the BC ABI. I'll test a patch.
I committed a patch to make pdftk use the system-installed libgcj instead of bundling libgcj classes. I didn't do the same for iText because pdftk's bundled iText implementation contains many local modifications. I've contacted the upstream maintainer about this. I'm going to close this bug and file a new one for the iText bundling, assigned to Jochen.