GCC/GCJ and pdftk

[Greg Larkin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe Auty wrote:
> 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"
>>>>> /usr/ports/lang/gcc42/work/gcc-4.2-20090325/libjava/gnu/gcj
>>>>> /usr/ports/lang/gcc42/work/gcc-4.2-20090325/libjava/gcj
>>>>> /usr/ports/lang/gcc42/work/build/gcc/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
>>> case,
>>> 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
>>> LIB_DEPENDS= gcj:${PORTSDIR}/lang/gcc${CSUFF}
>>
>>
>> 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
>>>> to>build/compile...
>>>
>>> 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
>>> work.
>>> 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.
>>>
>>>
>>> b.

Hi all,

I compiled gcc42+libgcj successfully and then print/pdftk without any
problems on 7.1-RELEASE amd64.  Still to do:

- - Run "make check" in gcc42 work directory to see if any problems pop up

- - Run some tests with pdftk on sample PDF files to check for problems

- - Contact gerald@ to find out if there are other reasons why libgcj
should not be enabled on amd64.

Cheers,
Greg
- --
Greg Larkin

http://www.FreeBSD.org/       - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKMEBM0sRouByUApARAgBdAKDE6iBJjevQu1zNNodBCKbm1yrCowCgnVNj
N2HCr1Ijz8paREMUr4GJUiI=
=xg4+
-----END PGP SIGNATURE-----