1 |
On Thursday 19 January 2012 04:35:43 Samuli Suominen wrote: |
2 |
> On 01/19/2012 11:19 AM, "Paweł Hajdan, Jr." wrote: |
3 |
> > While dealing with<https://bugs.gentoo.org/show_bug.cgi?id=393471> I |
4 |
> > started discussing with developers working on libjpeg-turbo support in |
5 |
> > WebKit, and I learned that despite |
6 |
> > <http://archives.gentoo.org/gentoo-dev/msg_e67bedf25dd178ec09a325a1220724 |
7 |
> > e6.xml> libjpeg-turbo is not necessarily binary compatible with libjpeg, |
8 |
> > and even with different versions of itself. |
9 |
> > |
10 |
> > Here's why. See |
11 |
> > <http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libj |
12 |
> > peg.txt?revision=299&view=markup> and search for "as a shared library". |
13 |
> > I'll paste the relevant quote here |
14 |
> > |
15 |
> > anyway: |
16 |
> >> While you can build the JPEG library as a shared library if the whim |
17 |
> >> strikes you, we don't really recommend it. The trouble with shared |
18 |
> >> libraries is that at some point you'll probably try to substitute a new |
19 |
> >> version of the library without recompiling the calling applications. |
20 |
> >> That generally doesn't work because the parameter struct declarations |
21 |
> >> usually change with each new version. In other words, the library's |
22 |
> >> API is *not* guaranteed binary compatible across versions; we only try |
23 |
> >> to ensure source-code compatibility. |
24 |
> > |
25 |
> > The particular problem with www-client/chromium is caused by |
26 |
> > <http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/im |
27 |
> > age-decoders/jpeg/JPEGImageDecoder.cpp> which sort of "hardcodes" in the |
28 |
> > compiled binary whether it was compiled against libjpeg-turbo with |
29 |
> > swizzle support (whatever that is) or not. |
30 |
> > |
31 |
> > The real problem here is that with above "no guarantee" of binary |
32 |
> > compatibility such a solution may be considered legitimate, especially |
33 |
> > that for e.g. Google Chrome the bundled copy of libjpeg-turbo is always |
34 |
> > used. |
35 |
> > |
36 |
> > What do you guys think we should do with this on the Gentoo side?At |
37 |
> |
38 |
> always use system libraries |
39 |
|
40 |
that doesn't help. the libjpeg turbo peeps themselves have said they don't |
41 |
guarantee compatibility across their own versions. |
42 |
|
43 |
> and i'm in process of dropping keywording |
44 |
> from media-libs/jpeg wrt[1] since we have no need for source slot of it |
45 |
|
46 |
err, no. libjpeg-turbo doesn't provide the older SONAME's like jpeg does. |
47 |
those SLOT's aren't going anywhere (SLOT!=0). |
48 |
|
49 |
history has shown that the canonical version stays around while the |
50 |
derivatives come and go. so until the seemingly braindead ABI policies of |
51 |
libjpeg-turbo can get sorted out, i don't think we can drop KEYWORDS on SLOT=0 |
52 |
jpeg. |
53 |
-mike |