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 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.
signature.asc
Description: OpenPGP digital signature
