Date: Fri, 5 Jun 2009 21:07:36 -0700 (PDT) From: bf <bf2006a@yahoo.com> To: Joe Auty <joe@netmusician.org> Cc: freebsd-questions@FreeBSD.org Subject: Re: GCC/GCJ and pdftk Message-ID: <770282.28623.qm@web39106.mail.mud.yahoo.com>
next in thread | raw e-mail | index | archive | help
--- On Fri, 6/5/09, Joe Auty <joe@netmusician.org> wrote:
> From: Joe Auty <joe@netmusician.org>
> Subject: Re: GCC/GCJ and pdftk
> To: "bf" <bf2006a@yahoo.com>
> Cc: freebsd-questions@FreeBSD.org
> Date: Friday, June 5, 2009, 10:42 PM
> 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.
To begin with, I don't know how you got this to work. Looking
at the lang/gcc42 port Makefile, version:
$FreeBSD: ports/lang/gcc42/Makefile,v 1.350 2009/05/26 14:26:22 gerald Exp $
beginning on line 81, most of the java-related stuff is set off by:
.if ! defined(WITHOUT_JAVA)
...
.endif
So merely defining WITHOUT_JAVA, whether you set it to yes, no, or
whatever, should have killed this part of the build. You need to
remove it from the build environment altogether to even attempt to build
the java components.
> > Yes, I did:
> >
> > $ ls /usr/local/bin/gcj*
> > /usr/local/bin/gcj42 /usr/local/bin/gcjh42
> >
Ok, so somehow these were installed (how, I don't know: see above.)
But do they *work*? Did they pass the regression tests of "make check"?
Just because you tinkered with the port and built them doesn't mean they
actually *work* on this architecture. As I've said, other people
(OpenBSD, Gentoo, Debian) have packages for amd64 versions of gcj, but
they had to add patches, and I don't know if they work properly, although
presumably the packagers did some testing. Some parts of a compiler
suite don't work on every architecture and OS.
> >
> >
> >>
> >>> 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}
> >
Ok, my mistake. If this had been BUILD_DEPENDS or RUN_DEPENDS, then
pdftk would have been looking for an executable named 'gcj' in your
PATH. But this is LIB_DEPENDS, which is handled differently by
Mk/bsd.port.mk. The stuff after the colon is just telling the Ports
infrastructure to install the port in ${PORTSDIR}/lang/gcc${CSUFF} if the
shared library libgcj.so.* isn't found by the ldconfig. Is "ldconfig -vr |
grep gcj" empty? If so, libgcj hasn't been built, installed, and
registered, so the java components of lang/gcc42 and things that depend
upon them won't work properly.
> >
> > 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.
Compile *and* work properly. I agree that this can and ought to be
fixed, but, again, it may not be as simple as changing a line or two
in the port Makefile.
> >>
> >> 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...
> >
All of the stuff I mentioned ought to work, with more or less effort on
your part. I'm no expert at this either, but it ought not to be too hard
to figure out. If you're just looking for a simple command-line tool,
I'd again suggest textproc/p5-CAM-PDF -- it comes with some simple Perl
scripts that are fairly close to pdftk in functionality, and only needs
Perl and a few other packages to run. I haven't used it much, but it
looks like what you say you want.
b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?770282.28623.qm>