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

[Samuli Suominen]

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_e67bedf25dd178ec09a325a1220724e6.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/libjpeg.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/image-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 and i'm in process of dropping keywording 
from media-libs/jpeg wrt[1] since we have no need for source slot of it

[1] http://bugs.gentoo.org/398909

both providers will be left in the virtual/jpeg, but only libjpeg-turbo 
will be keyworded (and thus supported), eliminating rest of the issues 
raised here

- Samuli

> this moment I've just reverted the mentioned change in
> www-client/chromium ebuild, but it's not feasible to keep a local patch
> too long (it needs rebasing too often).
>
> I was thinking about changing SONAMES, which would trigger rebuilds make
> things work, but then don't we rely on specific libjpeg SONAMES for
> binary-only software to work? Or does such binary-only software just use
> libjpeg-6b?
>
> Are there some other solutions we could apply on the Gentoo side? The
> main point here is that Chromium upstream considers
> <http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp>
> a legitimate change, and based on the referenced
> <http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299&view=markup>
> disclaimer about no guarantee of binary compatibility, I think it makes
> sense.
>