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
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
I hope you can give me any hint to solve the problem.
See Comment #1 on this bug report:
(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.