Joe Auty wrote:
bf wrote:

However, I've also read in the pdftk port logs that gcj is included in
GCC 3.4+ when WITHOUT_JAVA in the GCC Makefile is set to no or commented
out. So, I compiled GCC with gcj support without a problem, and

Oh yes, did you? Really? How? Better look again.

Sorry, I forgot to answer the "how" part of this: I simply build GCC42 with WITHOUT_JAVA set to no.

Yes, I did:

$ ls /usr/local/bin/gcj*
/usr/local/bin/gcj42 /usr/local/bin/gcjh42

commented out the NOT_FOR_ARCHS line above to force an install of pdftk:

===> pdftk-1.41 depends on executable: gmake - found
===> pdftk-1.41 depends on shared library: gcj - not found
===> Verifying install for gcj in /usr/ports/lang/gcc42
===> Returning to build of pdftk-1.41
Error: shared library "gcj" does not exist

gcj does indeed exist in /usr/ports/lang/gcc42:

# find /usr/ports/lang/gcc42 -name "gcj"

The "gcj" that the port is searching for must be the appropriate
binary executable, or a link to it, and must be in your PATH. In this
if properly installed via the port, it would be:

gcj42, gcj43, gcj44, or gcj45,

and would be in /usr/local/bin.

See above. The reason why I was thinking that for some reason it looks
for it in the port directory is the following in the Makefile:

# needs gcj

Perhaps I'm just misinterpreting things... It's strange though that the
reason for pdftk not building seems to be that gcj does not compile on
amd64 systems, when this doesn't seem to be true. I've read about
problems with memory consumption of gcj, but I don't know if these still
remain true - these posts were rather old.

However, again, all of this is with huge accuracy caveats, I'm
definitely not confident with my piecing together of information here...

All that you have done is find what I suspect are empty directories in
the WRKDIR for the lang/gcc42 port. Consider the 'which' command; or
limiting the directories searched and the using of '-not -type d' if
employing 'find' in this way in the future.

Any suggestions as to what I can do to build pdftk? This particular
project will surely be much harder if I can't get pdftk

In the order of increasing effort:

1) Use a tool other than pdftk to manipulate your PDF files. pdftk is
just a wrapper around an old version of devel/itext, structured with
the idea of compiling it with gcj. You could just install Java and
use the more up-to-date devel/itext. Or use print/ghostscript8,
graphics/poppler, or print/xpdf, either directly or via one of the many
programs (for example, print/kpdftool) that use them to do the dirty
Also textproc/p5-CAM-PDF, print/py-pdf, ...

I will definitely look at itext! I'm using FPDI to insert header stamps
into existing PDF files, and need something to rotate and merge PDFs.
I've looked at Ghostscript a little, but was really attracted to the
simplicity of doing this in pdftk. If you have any other suggestions of
solutions I could look into other than itext, I'd appreciate them! I'm
rather new to PDF manipulation...

2) Switch your system to i386 and use pdftk.

3) Find a way to build gcj on architectures other than i386, or persuade
or browbeat gerald@ into doing it. Debian has packages for other
architectures, for example. You could look at what they've done.


_______________________________________________ mailing list
To unsubscribe, send any mail to

Joe Auty
NetMusician: web publishing software for musicians
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to