Gentoo Archives: gentoo-dev

From: "Paweł Hajdan
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
Date: Thu, 19 Jan 2012 09:20:17
Message-Id: 4F17E01F.6080009@gentoo.org
1 While dealing with <https://bugs.gentoo.org/show_bug.cgi?id=393471> I
2 started discussing with developers working on libjpeg-turbo support in
3 WebKit, and I learned that despite
4 <http://archives.gentoo.org/gentoo-dev/msg_e67bedf25dd178ec09a325a1220724e6.xml>
5 libjpeg-turbo is not necessarily binary compatible with libjpeg, and
6 even with different versions of itself.
7
8 Here's why. See
9 <http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299&view=markup>
10 and search for "as a shared library". I'll paste the relevant quote here
11 anyway:
12
13 > While you can build the JPEG library as a shared library if the whim strikes
14 > you, we don't really recommend it. The trouble with shared libraries is that
15 > at some point you'll probably try to substitute a new version of the library
16 > without recompiling the calling applications. That generally doesn't work
17 > because the parameter struct declarations usually change with each new
18 > version. In other words, the library's API is *not* guaranteed binary
19 > compatible across versions; we only try to ensure source-code compatibility.
20
21 The particular problem with www-client/chromium is caused by
22 <http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp>
23 which sort of "hardcodes" in the compiled binary whether it was compiled
24 against libjpeg-turbo with swizzle support (whatever that is) or not.
25
26 The real problem here is that with above "no guarantee" of binary
27 compatibility such a solution may be considered legitimate, especially
28 that for e.g. Google Chrome the bundled copy of libjpeg-turbo is always
29 used.
30
31 What do you guys think we should do with this on the Gentoo side? At
32 this moment I've just reverted the mentioned change in
33 www-client/chromium ebuild, but it's not feasible to keep a local patch
34 too long (it needs rebasing too often).
35
36 I was thinking about changing SONAMES, which would trigger rebuilds make
37 things work, but then don't we rely on specific libjpeg SONAMES for
38 binary-only software to work? Or does such binary-only software just use
39 libjpeg-6b?
40
41 Are there some other solutions we could apply on the Gentoo side? The
42 main point here is that Chromium upstream considers
43 <http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp>
44 a legitimate change, and based on the referenced
45 <http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299&view=markup>
46 disclaimer about no guarantee of binary compatibility, I think it makes
47 sense.

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies