Bug#653061: libgs9 exports symbols conflicting with the same symbols in libjpeg8
Sample stack trace:
#0 0x00007fffef66486b in ?? () from /usr/lib/libgs.so.9
#1 0x00007fffeea3a997 in jinit_memory_mgr (cinfo=0x7ffffffea380)
at jmemmgr.c:1059
#2 0x00007fffeea1b32e in jpeg_CreateDecompress (cinfo=0x7ffffffea380,
version=<optimized out>, structsize=656) at jdapimin.c:59
#3 0x00007fffe1cee128 in ?? ()
from /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so
#4 0x00007ffff5b09d4e in ?? ()
from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#5 0x00007ffff5b0a03c in gdk_pixbuf_new_from_file ()
from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
Le vendredi 23 décembre 2011 à 23:27 +0100, Bill Allombert a écrit :
> On Fri, Dec 23, 2011 at 03:46:59PM -0600, Jonathan Nieder wrote:
> > Hi,
> >
> > Jean Brefort wrote:
> >
> > > Three symbols are concerned:
> > > jpeg_mem_init, jpeg_mem_term and jpeg_mem_available.
> > >
> > > Building an executable using the two libraries might crash. This happens for me
> > > with gnumeric (from git) when goffice is built with eps support and when I try
> > > to add a jpeg image inside a sheet.
>
> Hello,
>
> Since libjpeg8 uses versionned symbols, I would suggest libgs9 to use different
> symbol version for these three symbols.
>
> > More details would be useful, including a stacktrace or error messages
> > if possible.
> >
> > >From gs/base/sjpegc.c:
> >
> > Ghostscript uses a non-public interface to libjpeg in order to
> > override the library's default memory manager implementation.
>
> Is it still necessary with libjpeg8 ?
>
> > Do you know if libjpeg provides a way to use a custom allocator
> > without interfering with other modules in the same process image
> > that might not want to use it?
>
> I will ask upstream.
>
> Cheers,
Reply to: