libjpeg conflict in libgs
| 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://
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/
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:
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?

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.