libjpeg conflict in libgs

Bug #182623 reported by Carlos Garcia Campos
4
Affects Status Importance Assigned to Milestone
ghostscript (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: ghostscript

ghostscript includes its own version of libjpeg in the source code which it seems to be compiled statically. When using libgs from a program that dynamically links against the system libjpeg, this is used instead of the statically compiled libjpeg. This causes gs interpreter to fail for documents that contain a jpeg. It's only reporducible when the system libjpeg is linked before libgs.

You can use this small test program to reproduce the problem:

http://people.freedesktop.org/~carlosgc/test-libgs.c

It's a small gtk+ program that renders a ps file into the main window. The problem is reproducible depending on how the program is compiled.

$ gcc -g -Wall `pkg-config --cflags --libs gtk+-2.0` -ljpeg -lgs test-libgs.c -o test

It doesn't work. The following error is showed:

$ ./test /usr/share/texmf/tex/latex/advi/bar.eps
GPL Ghostscript 8.61 (2007-11-21)
Copyright (C) 2007 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /ioerror in --filter--
Operand stack:
   --nostringval-- Data --nostringval-- --dict:0/0(L)--
Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop --nostringval-- 1888 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1765 5 3 %oparray_pop
Dictionary stack:
   --dict:1153/1684(ro)(G)-- --dict:0/20(G)-- --dict:75/200(L)--
Current allocation mode is local
Current file position is 547
GPL Ghostscript 8.61: Unrecoverable error, exit code 1

$ gcc -g -Wall `pkg-config --cflags --libs gtk+-2.0` -lgs -ljpeg test-libgs.c -o test

It works

An easy work around whould be just compiling with the second command, but I'm using libgs from a plugin so that libgs si always linked after libjpeg.

So, is there any way to make sure libgs will always use the statically linked libjpeg?

Tags: testcase
Revision history for this message
Ralph Giles (giles-ghostscript) wrote :

Weird. I'd expect the jpeg symbols in gs to be resolved against the internal versions when the library is linked. Would it help to supply an exported symbol list? That would break anyone trying to use the graphics library directly, of course.

Ghostscript can actually link against the system libjpeg, but at the cost of not being able to support some files. The DCTDecode filter in Postscript was finalized before the baseline jpeg standard, and block runs are allowed to be longer that stock libjpeg will accept. It's just a define change, but that's why we compile against an internal version.

Revision history for this message
xteejx (xteejx) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Changed in ghostscript (Ubuntu):
status: New → Incomplete
Revision history for this message
Carlos Garcia Campos (carlosgc) wrote :

Yes, it's still reproducible in ubuntu karmic indeed, I've just uploaded a new verison of test-libgs.c, since we lost the old one.

$ gcc -g -Wall `pkg-config --cflags --libs gtk+-2.0` -ljpeg -lgs test-libgs.c -o test
$ ./test /usr/share/texmf/tex/latex/advi/bar.eps
GPL Ghostscript 8.70 (2009-07-31)
Copyright (C) 2009 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /ioerror in --filter--
Operand stack:
   --nostringval-- Data --nostringval-- --dict:0/0(L)--
Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1862 1 3 %oparray_pop 1861 1 3 %oparray_pop --nostringval-- 1845 1 3 %oparray_pop 1739 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1733 5 3 %oparray_pop
Dictionary stack:
   --dict:1158/1684(ro)(G)-- --dict:0/20(G)-- --dict:75/200(L)--
Current allocation mode is local
Current file position is 547
GPL Ghostscript 8.70: Unrecoverable error, exit code 1
$
$ gcc -g -Wall `pkg-config --cflags --libs gtk+-2.0` -lgs -ljpeg main.c -o test
$ ./test /usr/share/texmf/tex/latex/advi/bar.eps
GPL Ghostscript 8.70 (2009-07-31)
Copyright (C) 2009 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
$

Revision history for this message
xteejx (xteejx) wrote :

That's great! Thank you for updating this bug report, I have marked it Triaged, Medium. You may want to assign yourself if you are actively working on fixing this bug.

Changed in ghostscript (Ubuntu):
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

In our current Ghostscript the libgs uses the system libjpeg and no built-in one (we even remove the libjpeg source code from the source tarball of our Ghostscript package). So this problem and all similar library conflict problems should be solved.

Changed in ghostscript (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
kapouer (kapouer) wrote :

This is probably not fixed, see
http://bugs.debian.org/653061

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.