1 |
On Thu, 19 Jan 2012 10:19:27 +0100 |
2 |
""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote: |
3 |
|
4 |
> While dealing with <https://bugs.gentoo.org/show_bug.cgi?id=393471> I |
5 |
> started discussing with developers working on libjpeg-turbo support in |
6 |
> WebKit, and I learned that despite |
7 |
> <http://archives.gentoo.org/gentoo-dev/msg_e67bedf25dd178ec09a325a1220724e6.xml> |
8 |
> libjpeg-turbo is not necessarily binary compatible with libjpeg, and |
9 |
> even with different versions of itself. |
10 |
> |
11 |
> Here's why. See |
12 |
> <http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299&view=markup> |
13 |
> and search for "as a shared library". I'll paste the relevant quote |
14 |
> here anyway: |
15 |
> |
16 |
> > While you can build the JPEG library as a shared library if the |
17 |
> > whim strikes you, we don't really recommend it. The trouble with |
18 |
> > shared libraries is that at some point you'll probably try to |
19 |
> > substitute a new version of the library without recompiling the |
20 |
> > calling applications. That generally doesn't work because the |
21 |
> > parameter struct declarations usually change with each new |
22 |
> > version. In other words, the library's API is *not* guaranteed |
23 |
> > binary compatible across versions; we only try to ensure |
24 |
> > source-code compatibility. |
25 |
> |
26 |
> The particular problem with www-client/chromium is caused by |
27 |
> <http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp> |
28 |
> which sort of "hardcodes" in the compiled binary whether it was |
29 |
> compiled against libjpeg-turbo with swizzle support (whatever that |
30 |
> is) or not. |
31 |
> |
32 |
> The real problem here is that with above "no guarantee" of binary |
33 |
> compatibility such a solution may be considered legitimate, especially |
34 |
> that for e.g. Google Chrome the bundled copy of libjpeg-turbo is |
35 |
> always used. |
36 |
> |
37 |
> What do you guys think we should do with this on the Gentoo side? At |
38 |
> this moment I've just reverted the mentioned change in |
39 |
> www-client/chromium ebuild, but it's not feasible to keep a local |
40 |
> patch too long (it needs rebasing too often). |
41 |
> |
42 |
> I was thinking about changing SONAMES, which would trigger rebuilds |
43 |
> make things work, but then don't we rely on specific libjpeg SONAMES |
44 |
> for binary-only software to work? Or does such binary-only software |
45 |
> just use libjpeg-6b? |
46 |
|
47 |
Hmm, does this mean the ABI differs on runtime compilation options? |
48 |
SONAME should be changed with new versions, not options. If upstream |
49 |
does allow things like that, that's bad. If chromium uses that, it's |
50 |
even worse. |
51 |
|
52 |
I'd go with the simplest solution which is either enabling |
53 |
the particular configure option unconditionally or disabling it. |
54 |
If possible -- synced with SONAME change. But it should be upstream |
55 |
SONAME change (considering they do change SONAMEs when releasing |
56 |
binary-incompatible versions); we don't really want to go the Debian |
57 |
way, keeping our own SONAME cycles. |
58 |
|
59 |
-- |
60 |
Best regards, |
61 |
Michał Górny |