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.
