| 1 |
On 01/19/2012 06:56 PM, Mike Frysinger wrote: |
| 2 |
> On Thursday 19 January 2012 04:35:43 Samuli Suominen wrote: |
| 3 |
>> On 01/19/2012 11:19 AM, "Paweł Hajdan, Jr." wrote: |
| 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_e67bedf25dd178ec09a325a1220724 |
| 8 |
>>> e6.xml> libjpeg-turbo is not necessarily binary compatible with libjpeg, |
| 9 |
>>> and even with different versions of itself. |
| 10 |
>>> |
| 11 |
>>> Here's why. See |
| 12 |
>>> <http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libj |
| 13 |
>>> peg.txt?revision=299&view=markup> and search for "as a shared library". |
| 14 |
>>> I'll paste the relevant quote here |
| 15 |
>>> |
| 16 |
>>> anyway: |
| 17 |
>>>> While you can build the JPEG library as a shared library if the whim |
| 18 |
>>>> strikes you, we don't really recommend it. The trouble with shared |
| 19 |
>>>> libraries is that at some point you'll probably try to substitute a new |
| 20 |
>>>> version of the library without recompiling the calling applications. |
| 21 |
>>>> That generally doesn't work because the parameter struct declarations |
| 22 |
>>>> usually change with each new version. In other words, the library's |
| 23 |
>>>> API is *not* guaranteed binary compatible across versions; we only try |
| 24 |
>>>> to ensure 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/im |
| 28 |
>>> age-decoders/jpeg/JPEGImageDecoder.cpp> which sort of "hardcodes" in the |
| 29 |
>>> compiled binary whether it was compiled against libjpeg-turbo with |
| 30 |
>>> swizzle support (whatever that 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 always |
| 35 |
>>> used. |
| 36 |
>>> |
| 37 |
>>> What do you guys think we should do with this on the Gentoo side?At |
| 38 |
>> |
| 39 |
>> always use system libraries |
| 40 |
> |
| 41 |
> that doesn't help. the libjpeg turbo peeps themselves have said they don't |
| 42 |
> guarantee compatibility across their own versions. |
| 43 |
|
| 44 |
it's forward compatible, which is all we should care about |
| 45 |
|
| 46 |
>> and i'm in process of dropping keywording |
| 47 |
>> from media-libs/jpeg wrt[1] since we have no need for source slot of it |
| 48 |
> |
| 49 |
> err, no. libjpeg-turbo doesn't provide the older SONAME's like jpeg does. |
| 50 |
> those SLOT's aren't going anywhere (SLOT!=0). |
| 51 |
|
| 52 |
i said "source slot" which was supposed to mean SLOT="0" alone, the |
| 53 |
SLOT="62" will still have keywording, SLOT="7" is not used anything in |
| 54 |
tree but can still have the keywording (unintresting to this topic) |
| 55 |
|
| 56 |
> history has shown that the canonical version stays around while the |
| 57 |
> derivatives come and go. |
| 58 |
|
| 59 |
and the ones before never had this level of people behind it, and |
| 60 |
projects where people get paid to get it working, like fedora |
| 61 |
|
| 62 |
> so until the seemingly braindead ABI policies of |
| 63 |
> libjpeg-turbo can get sorted out, i don't think we can drop KEYWORDS on SLOT=0 |
| 64 |
> jpeg. |
| 65 |
|
| 66 |
the only thing that's really broken is building against libjpeg-turbo, |
| 67 |
and then switching to ijg's jpeg without rebuilding the package |
| 68 |
|
| 69 |
and downgrading of libjpeg-turbo |
| 70 |
|
| 71 |
both of which are not worth of supporting |
Archives