Bug 236224

+++ 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
BC ABI.

-- Additional comment from Jochen 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

http://www.herr-schmitt.de/pub/pdftk/

I hope you can give me any hint to solve the problem.

Best Regards:

Jochen Schmitt

-- Additional comment from fitzsim on 2007-03-25 22:00 EST --
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.)


-- Additional comment from fitzsim 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 fitzsim 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.