ghostscript-gpl fails to build with the following error: ./pdf/pdf_file.c:57:12: fatal error: sjpx.h: No such file or directory 57 | # include "sjpx.h" Reproducible: Always Steps to Reproduce: 1. Build app-text/ghostscript-gpl-9.54.0-r1 with USE="cups unicode -X -dbus -gtk -jpeg2k -static-libs" Actual Results: ghostscript-gpl fails to build. Expected Results: ghostscript-gpl should have been built successfully. The offending include is in the following code within ./pdf/pdf_file.c: #if defined(USE_LWF_JP2) # include "sjpx_luratech.h" #elif defined(USE_OPENJPEG_JP2) # include "sjpx_openjpeg.h" #else # include "sjpx.h" #endif Looks like it's related to Jpeg2000 format support, which is disabled in USE flags. Also, sjpx.h is nowhere to be found in the source directory: $ find -iname "sjpx*" | grep -v '\.o$' ./base/sjpx_none.c ./base/sjpx_openjpeg.h ./base/sjpx_openjpeg.c Simply commenting out #include "sjpx.h" does not work since it's used in pdfi_JPX_filter function. Putting the dependent function into an ifdef seems to be working. The patch is attached.
Created attachment 745989 [details] build.log.bz2
Created attachment 745992 [details, diff] Patch to fix build failures when jpeg2000 support is disabled.
It could be possible that we have to depend on jpeg2000 in future. The code is in their new PDFi, currently disabled by default but they hope to switch to the new engine with 9.56 release.
(In reply to Thomas Deutschmann from comment #3) > It could be possible that we have to depend on jpeg2000 in future. The code > is in their new PDFi, currently disabled by default but they hope to switch > to the new engine with 9.56 release. I didn't go very deep, but presence of sjpx_none.c with "Dummy for no JPX support" comments might indicate that an option to forgo jpeg2000 support is at least considered.
This was added in https://git.ghostscript.com/?p=ghostpdl.git;a=commit;f=pdf/pdf_file.c;h=00964d2267fa7d031d62ed5021aec0982ded47a6 and is part of the new PDF engine which was merged in 9.55 but is disabled by default for now (for 9.56 release they plan to enable it by default). I am going to drop USE=jpeg2000 so that the package will unconditionally depend on media-libs/openjpeg so that you can do the same with Ghostscript in Gentoo like you can do in RHEL/Debian out-of-the box -- note that JPX is part PDF/A-2 standard (we had a similar request recently for imagemagick where we offer HEIF support via USE flag but didn't depend on libheif with capabilities enabled to actually write HEIF images).
(In reply to Thomas Deutschmann from comment #5) > is part of the new PDF engine > which was merged in 9.55 but is disabled by default for now (for 9.56 > release they plan to enable it by default). Okay. Interesting that code for a disabled engine is causing compile errors now. > I am going to drop USE=jpeg2000 so that the package will unconditionally > depend on media-libs/openjpeg so that you can do the same with Ghostscript > in Gentoo like you can do in RHEL/Debian out-of-the box For me it sounds more like an argument for enabling the use flag by default and not for dropping the flag altogether. But if the upstream is not going to support this option, sure.
(In reply to Alexander Sergeyev from comment #6) > (In reply to Thomas Deutschmann from comment #5) > > is part of the new PDF engine > > which was merged in 9.55 but is disabled by default for now (for 9.56 > > release they plan to enable it by default). > > Okay. Interesting that code for a disabled engine is causing compile errors > now. I think there is a misunderstanding regarding the meaning of "disabled engine". To quote upstream release notes: > In this (9.55.0) release, the new PDF interpreter is disabled by default in Ghostscript, but can be used by specifying -dNEWPDF. We hope to make it the default in 9.56.0, and fully deprecate the PostScript implementation shortly after that (depending on the feedback we get). So Ghostscript 9.55.0 won't use the new PDF interpreter by default. But if you already want to start using it, you can by specifying -dNEWPDF. > > I am going to drop USE=jpeg2000 so that the package will unconditionally > > depend on media-libs/openjpeg so that you can do the same with Ghostscript > > in Gentoo like you can do in RHEL/Debian out-of-the box > > For me it sounds more like an argument for enabling the use flag by default > and not for dropping the flag altogether. But if the upstream is not going > to support this option, sure. If you care about this, feel free to ask upstream if they want to make JPX optional again. I am not going to do that because JPX support is in PDF specs and my opinion is that PDF should just work out-of-the box. It's hard to explain someone (see the imagemagick bugs) that you have PDF support but you cannot create PDF for long-term archiving until you enable... which works out-of-the box in Fedora/RHEL, Arch, Debian & Ubuntu. But if they make it optional again, sure, we can restore USE flag but enable it by default.
(In reply to Thomas Deutschmann from comment #7) > I think there is a misunderstanding regarding the meaning of "disabled > engine". [...] Okay, makes sense. > If you care about this, feel free to ask upstream if they want to make JPX > optional again. I don't greatly care about this for the particular package, but, overall, system-wide customizability is one of important and distinct features of gentoo compared to other distros (at least in my view). > [...] It's hard > to explain someone (see the imagemagick bugs) that you have PDF support but > you cannot create PDF for long-term archiving until you enable... which > works out-of-the box in Fedora/RHEL, Arch, Debian & Ubuntu. Well, I think this is an inherent cost for having such flexibility in the distro, and people should generally understand this after going through the first install. But I get the point.
(In reply to Alexander Sergeyev from comment #8) > Well, I think this is an inherent cost for having such flexibility in the > distro, [...] I mean the cost of taking time to work through USE flags and consequences of the choices; especially when going off the default profile.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=261af8f6bc4a5a3a2d902cd0b0770a7ac91715b8 commit 261af8f6bc4a5a3a2d902cd0b0770a7ac91715b8 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2021-10-21 15:26:57 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2021-10-21 18:08:17 +0000 app-text/ghostscript-gpl: drop USE=jpg2000 New PDF interpreter requires JPX support. Closes: https://bugs.gentoo.org/819117 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> ...ostscript-gpl-9.55.0.ebuild => ghostscript-gpl-9.55.0-r1.ebuild} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
