Arch Linux

openjpg2 is in the repos.

Sure ok, however the issue is then;

cups-filters: requires poppler
poppler: requires openjpeg

I came across this while trying to print orginally.

Thus I guess, can poppler be update to link to openjpeg2
instead and why is it not already? Many issues were resolved
in 2.0.0 over 1.5.x after digging in.

Kind Regards,

Look at http://bugs.ghostscript.com/show_bug.cgi?id=694311 and

http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=66d9c0aa17a5abcecd6590e63f0620f7aa51634c

The code hasn't landed in GS 9.10 but only in git master. We will have to wait for a release including these fixes.
That's a major change we can't backport.

OK I do know however, that if I compile openjpeg 2.0.0 from source by adjusting the
PKGBUILD and overwrite the openjpeg 1.5.1-1 package the issue magically goes away.

It maybe prudent to add yourself to the upstream CC list Andreas Radke (AndyRTR) if you don't mind?
Since I really don't know how so many of these smaller component libraries work together in this particular case.

Kind Regards,
Edward.
P.S. Thanks for looking into this.

After talking upstream it does sound like the best cause of action
for Andreas Radke (AndyRTR) as you are assigned to this would be to
communicate with upstream directly going forward.

There is plenty of background narrowing down the problem, although
not complete to the exact line admittedly. It should be trivial to
replicated with all the provided information provided in the upstream bug.

The issue seems a bit more complex than; `wait a couple of weeks for
GS to bump a new release, nothing to see here..`

Thanks,
Edward.

http://bugs.ghostscript.com/show_bug.cgi?id=694861#c7 seems quite clear:

"*our* version of the OpenJPEG libraries incorporates patches... *don't* use system shared libraries"

and comment 18:

"The only safe route is to build with our bundled (patched) versions."

So I would suggest trying to compile ghostscript *without* this line in ghostscript's PKGBUILD:

rm -rf jpeg libpng zlib jasper expat tiff lcms lcms2 freetype openjpeg cups/libs

And I suppose, also remove "--with-system-libtiff"

Paul Bredbury (brebs) solution is correct, I also rebuilt the package to confirm as to be sure.

This change also makes prints sharper looking as a added benefit.

Cheers,
Edward.
P.S. Merry Capitalism :)

We should try to keep benefits from linking to system libs wherever possible to gain lower memory footprint,
quick upstream security fixes and so on.

Checking the Fedora and Debian builds both also use system libraries for libjpeg and system openjpeg. Openjpeg seems to
be only needed at build time as a makedep. So it should be safe to use included openjpeg and keep using system libjpeg-turbo.

Can somebody who's affected please do a ghostscript rebuild with chaning the cleanup line in the PKGBUILD to:

rm -rf jpeg jpegxr libpng zlib jasper expat tiff lcms lcms2 freetype cups/libs

This would be the way I prefer it. If it still gives segfaults we can also try

rm -rf jpegxr libpng zlib jasper expat tiff lcms lcms2 freetype cups/libs - but this could lead to a much slower picture handling.

If you can confirm a minimum change we need to apply I'll push a package to our testing repo.

Can you provide a simple test case with its command and file that gives reproducible segfaults so I can test locally?

I've found the Absolute_OpenBSD_UNIX_for_the_Practical_Paranoid_1886411999.pdf you've mentioned in your bug report and I could easily print the file
from Evince to my virtual pdf printer without a segfault.

So I need a proper test case to be able to reproduce it. If you don't provide such use case I can't confirm a possible fix.

I've found a test case: gsx PLANHALF.pdf - the file is from http://bugs.ghostscript.com/show_bug.cgi?id=688869 (see http://bugs.ghostscript.com/show_bug.cgi?id=694449).

I could solve it with gs 9.10-2 that is just going to our testing repo. Please check if it also solves your error/segfault.