+++ This bug was initially created as a clone of Bug #233514 +++
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
-- Additional comment from Jochen@herr-schmitt.de on 2007-03-25 16:05 EST --
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.
-- Additional comment from firstname.lastname@example.org on 2007-03-25 22:00 EST --
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.)
-- Additional comment from email@example.com on 2007-03-26 12:17 EST --
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.
-- Additional comment from firstname.lastname@example.org on 2007-04-12 11:45 EST --
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.
Because iText is going into EOL during licensing issues, I will start the EOL
for pdftk which contains a bundled version of iText.
Please see BZ #236309