Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

[Mike Frysinger]

On Thursday 19 January 2012 04:35:43 Samuli Suominen wrote:
> On 01/19/2012 11:19 AM, "Paweł Hajdan, Jr." wrote:
> > While dealing with<https://bugs.gentoo.org/show_bug.cgi?id=393471>  I
> > started discussing with developers working on libjpeg-turbo support in
> > WebKit, and I learned that despite
> > <http://archives.gentoo.org/gentoo-dev/msg_e67bedf25dd178ec09a325a1220724
> > e6.xml> libjpeg-turbo is not necessarily binary compatible with libjpeg,
> > and even with different versions of itself.
> >
> > Here's why. See
> > <http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libj
> > peg.txt?revision=299&view=markup> and search for "as a shared library".
> > I'll paste the relevant quote here
> >
> > anyway:
> >> While you can build the JPEG library as a shared library if the whim
> >> strikes you, we don't really recommend it.  The trouble with shared
> >> libraries is that at some point you'll probably try to substitute a new
> >> version of the library without recompiling the calling applications.
> >> That generally doesn't work because the parameter struct declarations
> >> usually change with each new version.  In other words, the library's
> >> API is *not* guaranteed binary compatible across versions; we only try
> >> to ensure source-code compatibility.
> >
> > The particular problem with www-client/chromium is caused by
> > <http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/im
> > age-decoders/jpeg/JPEGImageDecoder.cpp> which sort of "hardcodes" in the
> > compiled binary whether it was compiled against libjpeg-turbo with
> > swizzle support (whatever that is) or not.
> >
> > The real problem here is that with above "no guarantee" of binary
> > compatibility such a solution may be considered legitimate, especially
> > that for e.g. Google Chrome the bundled copy of libjpeg-turbo is always
> > used.
> >
> > What do you guys think we should do with this on the Gentoo side?At
>
> always use system libraries

that doesn't help.  the libjpeg turbo peeps themselves have said they don't 
guarantee compatibility across their own versions.

> and i'm in process of dropping keywording
> from media-libs/jpeg wrt[1] since we have no need for source slot of it

err, no.  libjpeg-turbo doesn't provide the older SONAME's like jpeg does.  
those SLOT's aren't going anywhere (SLOT!=0).

history has shown that the canonical version stays around while the 
derivatives come and go.  so until the seemingly braindead ABI policies of 
libjpeg-turbo can get sorted out, i don't think we can drop KEYWORDS on SLOT=0 
jpeg.
-mike