Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 562568

Summary: =app-text/pdftk-2.02 calls gcj directly
Product: Gentoo Linux Reporter: Jeroen Roovers <jer>
Component: [OLD] PrintingAssignee: Printing Team <printing>
Status: RESOLVED FIXED    
Severity: normal CC: adpc, ainsaar, amlabs, devurandom, email200202, fitzcarraldo1, flyser42, gentoo, harrisl, hrabe, jan_braun, jarausch, java, jdavid.ibp, leonard, melnikovsky, mrc_timer, mrueg, nickAristocrates, Oliver, ostroffjh, pacho, pi314, rossi.f, t-mo, tb, till2.schaefer, toralf, trent2, zorry
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://github.com/gentoo/gentoo/pull/7712
Whiteboard:
Package list:
Runtime testing required: ---

Description Jeroen Roovers gentoo-dev 2015-10-08 14:24:14 UTC
In Makefile.Debian it looks like the TOOLPATH variable could be overridden in order to get a full toolchain tuple.
Comment 1 James Le Cuirot gentoo-dev 2015-10-08 14:46:50 UTC
Is it possible to use a normal Java compiler instead? gcj's days are numbered and we do intend to remove it eventually.
Comment 2 gentoo 2016-07-05 17:56:27 UTC
PdfTk is now broken:

mfld@home $ pdftk
pdftk: error while loading shared libraries: libgcj.so.14: cannot open shared object file: No such file or directory

Still requires libgcj that is no more installed, nor required as dependency:

mfld@home $ equery g pdftk
 * Searching for pdftk ...

 * dependency graph for app-text/pdftk-2.02
 `--  app-text/pdftk-2.02  amd64 
   `--  sys-devel/gcc-4.9.3  (sys-devel/gcc) amd64  [gcj]
[ app-text/pdftk-2.02 stats: packages (2), max depth (1) ]
Comment 3 gentoo 2016-07-05 18:15:06 UTC
Problem solved by emerging manually, to force the update of the libgjc reference to the right & latest version.
Comment 4 Jeroen Roovers gentoo-dev 2016-07-05 22:04:56 UTC
(In reply to mfld.fr from comment #3)
> Problem solved by emerging manually, to force the update of the libgjc
> reference to the right & latest version.

That's an entirely different bug. Please report it separately.
Comment 5 gentoo 2016-07-06 16:49:59 UTC
OK, reported as https://bugs.gentoo.org/show_bug.cgi?id=588176.
Comment 6 Michael Palimaka (kensington) gentoo-dev 2017-02-11 08:09:45 UTC
*** Bug 608246 has been marked as a duplicate of this bug. ***
Comment 7 Yi Yang 2017-02-15 15:13:18 UTC
Hi all,

I noticed that pdftk fails to build with GCC-6.3.0 with default useflags, the only issue being that GCC-6.3.0 by default disabled gcj but still provides support for that useflag.

I understand that gcj is going to be removed eventually, but that's a long-term thing and a much more near-term thing is that our dependency between pdftk and gcc[gcj] is missing in the ebuilds. Could we fix the ebuild first, talk about fixing pdftk's build system or toolchain support later?

Thanks a lot.
Comment 8 Helmut Jarausch 2017-02-15 15:44:55 UTC
(In reply to Yi Yang from comment #7)
> Hi all,
> 
> I noticed that pdftk fails to build with GCC-6.3.0 with default useflags,
> the only issue being that GCC-6.3.0 by default disabled gcj but still
> provides support for that useflag.
> 

I don't think so. I do have the gcj use flag but it is ignored when building gcc-6.3.0
Comment 9 Andreas K. Hüttel gentoo-dev 2017-02-17 21:08:19 UTC
Lengthy googling found this, not tested yet...
https://gist.github.com/jpmckinney/1840053
Comment 10 Andreas K. Hüttel gentoo-dev 2017-02-19 18:35:38 UTC
*** Bug 595414 has been marked as a duplicate of this bug. ***
Comment 11 Andrew John Hughes 2017-02-20 01:53:15 UTC
Looks like a hack to me. The build system would need a rewrite to fix this, removing all the references to object files, as other JDKs don't provide ahead-of-time compilation. That patch doesn't fix that:

-	$(GCJ) $(GCJFLAGS) -c java_lib.jar
+	$(GCJ) $(GCJFLAGS) -c java_lib.jar # @todo this is a problem

Is pdftk still needed? It looks like Fedora hasn't built it since 2013:

https://koji.fedoraproject.org/koji/packageinfo?packageID=2742
Comment 12 James Le Cuirot gentoo-dev 2017-04-18 21:59:00 UTC
With gcc 5 having just gone stable, we're now another step closer to dropping gcj. I took a closer look at this and it's really not just using gcj in the build system. The whole thing is wedded closely to gcj and changing that is very non-trivial. It is very telling that upstream promised a non-gcj version some two years ago and still haven't delivered. No wonder Fedora stopped packaging it. I know this software is quite unique but be prepared to let it go if upstream don't deliver.
Comment 13 Dennis Schridde 2017-05-13 16:11:12 UTC
Broken with sys-devel/gcc-6.3.0:
# Magnus Granberg <zorry@gentoo.org> (18 Jan 2017)
# Adding the mask so that end users and devlopers are notified of the removal and have some
# time to migrate. There is no support for gcj in gcc-7
>=sys-devel/gcc-6.3.0 gcj
Comment 14 gentoo 2017-05-14 07:27:09 UTC
*** Bug 588176 has been marked as a duplicate of this bug. ***
Comment 15 Jonas Stein gentoo-dev 2017-05-21 19:00:29 UTC
*** Bug 617790 has been marked as a duplicate of this bug. ***
Comment 16 Viacheslav Ostroukh 2017-11-19 22:24:30 UTC
This bug becomes more important since =sys-devel/gcc-6.4.0 stabilization, that can't build stable =app-text/pdftk-2.02. Shouldn't pdftk be masked then, since gcj use flag is masked?
Comment 17 Marcel 2017-11-20 18:52:03 UTC
(In reply to Viacheslav Ostroukh from comment #16)
> This bug becomes more important since =sys-devel/gcc-6.4.0 stabilization,
> that can't build stable =app-text/pdftk-2.02. Shouldn't pdftk be masked
> then, since gcj use flag is masked?

Seconded. I just ran into this issue.

Despite gcj use flags and installed pdftk the upgrade to gcc-6 stable proceeds and breaks the compile of pdftk now.
Comment 18 Jack 2017-11-20 23:48:32 UTC
I actually sent an email to the upstream maintainer on 10 Oct, but have received no response.  I couldn't find any evidence of forum or discussion area on the upstream web site.  It also looks like the latest release is four years old, and the latest copyright date is 2014.  I found a newer email address through his presence on the O'Reilly site, and will post back here if I get any response from that address.
Comment 19 Viacheslav Ostroukh 2017-11-21 22:08:42 UTC
(In reply to Jack from comment #18)
> I actually sent an email to the upstream maintainer on 10 Oct, but have
> received no response.  I couldn't find any evidence of forum or discussion
> area on the upstream web site.  It also looks like the latest release is
> four years old, and the latest copyright date is 2014.  I found a newer
> email address through his presence on the O'Reilly site, and will post back
> here if I get any response from that address.

I am far from being a maintainer, but I would really consider masking it (even for removal, may be). As I see, mutool from app-text/mupdf covers most of its functionality and actively maintained, it may be suggested as an alternative.
Comment 20 Erik Quaeghebeur 2017-11-22 08:52:24 UTC
(In reply to Viacheslav Ostroukh from comment #19)
> As I see, mutool from app-text/mupdf covers most
> of its functionality and actively maintained, it may be suggested as an
> alternative.
Another alternative is app-text/qpdf.
Comment 21 Aurelien Minet 2017-11-23 08:51:03 UTC
I had a look to mupdf and qpdf but they doesn't cover all the functionalities of pdftk, mainly the most useful: filling forms with a fdf/xfdf file.
Maybe something based on Poppler or iText could do the job.
Comment 22 Larry the Git Cow gentoo-dev 2017-11-27 17:45:04 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7a0a8d6e5c3b03291d696124367821116ccbe5d4

commit 7a0a8d6e5c3b03291d696124367821116ccbe5d4
Author:     Andreas K. Huettel <dilfridge@gentoo.org>
AuthorDate: 2017-11-27 17:43:52 +0000
Commit:     Andreas K. Huettel <dilfridge@gentoo.org>
CommitDate: 2017-11-27 17:44:42 +0000

    app-text/pdftk: Make this build with gcc-5 for now
    
    Hardwire pdftk to use gcc-5.4.0, and depend on it
    
    Bug: https://bugs.gentoo.org/562568
    Package-Manager: Portage-2.3.16, Repoman-2.3.6

 app-text/pdftk/pdftk-2.02.ebuild | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)}
Comment 23 Alexander Bezrukov 2017-12-29 15:34:23 UTC
Since gcc-6.4 is still supported by Gentoo and probably will continue to be supported for some more time and because pdftk works well and there seems to be neither comparable replacement nor migration to javac by upstream, I would suggest to fix ebuild like this

-RDEPEND="sys-devel/gcc:5.4.0[gcj]"
+RDEPEND="<sys-devel/gcc-7[gcj]"

Then it would be up to the user to either unmask the package and gcj USE flag for gcc and continue to be happy until gcc-6 deprecation, or seek for ways to immediately change his/her workflow.
Comment 24 Jack 2017-12-30 00:29:48 UTC
(In reply to Jack from comment #18)
> I actually sent an email to the upstream maintainer on 10 Oct, but have received no response.  [snip]  I found a newer email address through his presence on the O'Reilly site, and will post back here if I get any response from that address.
Now over a month later, and no reply to either email.  It really does look dead upstream.
Comment 25 Larry the Git Cow gentoo-dev 2018-01-04 15:08:27 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ce2f044cc673a6d08cd8a40459bd0dbf66df864e

commit ce2f044cc673a6d08cd8a40459bd0dbf66df864e
Author:     Patrice Clement <monsieurp@gentoo.org>
AuthorDate: 2018-01-04 14:30:42 +0000
Commit:     Patrice Clement <monsieurp@gentoo.org>
CommitDate: 2018-01-04 15:07:54 +0000

    dev-python/stapler: new ebuild.
    
    stapler is a suite of tools for PDF files manipulation. It makes use of
    the PyPDF2 library to provide a (somewhat) lighter alternative to pdftk.
    
    See https://github.com/hellerbarde/stapler.
    
    Bug: https://bugs.gentoo.org/562568
    
    Package-Manager: Portage-2.3.13, Repoman-2.3.3
    Reviewed-by: James Le Cuirot <chewi@gentoo.org>

 dev-python/stapler/Manifest                     |  1 +
 dev-python/stapler/metadata.xml                 | 11 ++++++++++
 dev-python/stapler/stapler-0.4_p20160424.ebuild | 29 +++++++++++++++++++++++++
 3 files changed, 41 insertions(+)}
Comment 26 Patrice Clement gentoo-dev 2018-01-04 20:09:32 UTC
Hi there!

First, thank you Manuel for the suggestion. We were looking really hard for an alternative to pdftk.

I think stapler is the last nail in pdftk's coffin. We encourage everybody CC'ed in to give it a go and will wait 30 days for some feedback so that you have ample time to tinker with it. If there's no objection until then, we will mask pdftk for removal.
Comment 27 Robert Spillner 2018-01-04 23:14:47 UTC
In https://github.com/hellerbarde/stapler/blob/master/TODO there's a comparison between pdftk features and stapler features. Unfortunately, forms e.g. are not (yet?) supported. To my knowledge there's no other tool supporting this. Are we too early to nail the coffin?
Comment 28 James Le Cuirot gentoo-dev 2018-01-04 23:31:52 UTC
We are a little earlier than we might have been. Another dev masked the gcj flag against gcc 6 even though it wasn't removed by upstream until 7. I had assumed that there was additional work needed to support it on 6 but now I think adjusting the mask is all that is needed.

I'm CC'ing Zorry, who added the mask, to get his opinion.
Comment 29 Fitzcarraldo 2018-02-22 08:28:57 UTC
The following third-party rewrite of pdftk to remove gcj requirement looks interesting:

https://gitlab.com/marcvinyals/pdftk

http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk-9999.ebuild

Ref: https://forums.gentoo.org/viewtopic-p-8187088.html#8187088
Comment 30 Magnus Granberg gentoo-dev 2018-02-23 01:07:15 UTC
(In reply to James Le Cuirot from comment #28)
> We are a little earlier than we might have been. Another dev masked the gcj
> flag against gcc 6 even though it wasn't removed by upstream until 7. I had
> assumed that there was additional work needed to support it on 6 but now I
> think adjusting the mask is all that is needed.
> 
> I'm CC'ing Zorry, who added the mask, to get his opinion.
Gcc 7 has allready a bug open for stabilization. So gcj's days are numbered.
Comment 31 Joseph 2018-03-15 20:25:08 UTC
(In reply to Fitzcarraldo from comment #29)
> The following third-party rewrite of pdftk to remove gcj requirement looks
> interesting:
> 
> https://gitlab.com/marcvinyals/pdftk
> 
> http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk-
> 9999.ebuild
> 
> Ref: https://forums.gentoo.org/viewtopic-p-8187088.html#8187088

I've compiled the pdftk-9999 (java based)
gcc-5.4.0-r4 is gone and pdftk is working as it should.
Comment 32 Bodo Graumann 2018-03-16 09:06:33 UTC
(In reply to Joseph from comment #31)
> I've compiled the pdftk-9999 (java based)
> gcc-5.4.0-r4 is gone and pdftk is working as it should.

That sounds great. Can we please have that ebuild in testing?
Comment 33 Joseph 2018-03-16 16:06:23 UTC
(In reply to Bodo Graumann from comment #32)
> (In reply to Joseph from comment #31)
> > I've compiled the pdftk-9999 (java based)
> > gcc-5.4.0-r4 is gone and pdftk is working as it should.
> 
> That sounds great. Can we please have that ebuild in testing?

The ebuild "pdftk-9999" is here:

http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk-9999.ebuild

Forum related link:
https://forums.gentoo.org/viewtopic-t-1070648-highlight-.html
Comment 34 Grant Edwards 2018-03-16 16:29:53 UTC
(In reply to Joseph from comment #33)
> (In reply to Bodo Graumann from comment #32)
> > (In reply to Joseph from comment #31)
> > > I've compiled the pdftk-9999 (java based)
> > > gcc-5.4.0-r4 is gone and pdftk is working as it should.
> > 
> > That sounds great. Can we please have that ebuild in testing?

Here's another vote for that!

> The ebuild "pdftk-9999" is here:
> 
> http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk-
> 9999.ebuild
> 
> Forum related link:
> https://forums.gentoo.org/viewtopic-t-1070648-highlight-.html

I've switched to the ebuild above, and it works great.

I looked (rather briefly) at various replacements (including stapler) and didn't find anything that could apply a watermark to a document from the command-line.
Comment 35 Kristian Niemi 2018-04-04 09:05:09 UTC
(In reply to Joseph from comment #33)
> 
> The ebuild "pdftk-9999" is here:
> 
> http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk-
> 9999.ebuild
> 
> Forum related link:
> https://forums.gentoo.org/viewtopic-t-1070648-highlight-.html

+1. Works great!
Comment 36 Larry the Git Cow gentoo-dev 2018-04-08 22:42:20 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=09e0550990ea6cf5232ba3c0a11c933aa01d52d6

commit 09e0550990ea6cf5232ba3c0a11c933aa01d52d6
Author:     charIes17 <charles17@arcor.de>
AuthorDate: 2018-03-30 14:40:11 +0000
Commit:     Patrice Clement <monsieurp@gentoo.org>
CommitDate: 2018-04-08 22:42:07 +0000

    app-text/pdftk: add live ebuild with different upstream.
    
    Bug: https://bugs.gentoo.org/562568
    
    See https://forums.gentoo.org/viewtopic-p-8187088.html#8187088
    
    Package-Manager: Portage-2.3.24, Repoman-2.3.6
    Closes: https://github.com/gentoo/gentoo/pull/7712

 app-text/pdftk/pdftk-9999.ebuild | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)}
Comment 37 Patrice Clement gentoo-dev 2019-05-14 20:38:06 UTC
Let's mark this bug as FIXED this everybody seems happy with this version of pdftk. Thanks everyone!