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. |