From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RnvRD-0003n7-1v for garchives@archives.gentoo.org; Thu, 19 Jan 2012 17:06:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E0C04E0A5C; Thu, 19 Jan 2012 17:05:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C8D9EE0A63 for ; Thu, 19 Jan 2012 17:05:03 +0000 (UTC) Received: from [85.78.96.201] (GGMYI.gprs.sl-laajakaista.fi [85.78.96.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ssuominen) by smtp.gentoo.org (Postfix) with ESMTPSA id 26F921B402A for ; Thu, 19 Jan 2012 17:05:00 +0000 (UTC) Message-ID: <4F184CB8.2040302@gentoo.org> Date: Thu, 19 Jan 2012 19:02:48 +0200 From: Samuli Suominen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111120 Thunderbird/8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility References: <4F17E01F.6080009@gentoo.org> <4F17E3EF.2070706@gentoo.org> <201201191156.06226.vapier@gentoo.org> In-Reply-To: <201201191156.06226.vapier@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: cb506a3a-10cd-4918-94a6-146fb5c6c207 X-Archives-Hash: 845ace82f5bcf4f955d4bd7d0e6dac9f On 01/19/2012 06:56 PM, Mike Frysinger wrote: > On Thursday 19 January 2012 04:35:43 Samuli Suominen wrote: >> On 01/19/2012 11:19 AM, "Pawe=C5=82 Hajdan, Jr." wrote: >>> While dealing with = I >>> started discussing with developers working on libjpeg-turbo support i= n >>> WebKit, and I learned that despite >>> >> e6.xml> libjpeg-turbo is not necessarily binary compatible with libj= peg, >>> and even with different versions of itself. >>> >>> Here's why. See >>> >> peg.txt?revision=3D299&view=3Dmarkup> and search for "as a shared li= brary". >>> I'll paste the relevant quote here >>> >>> anyway: >>>> While you can build the JPEG library as a shared library if the whim >>>> strikes you, we don't really recommend it. The trouble with shared >>>> libraries is that at some point you'll probably try to substitute a = new >>>> version of the library without recompiling the calling applications. >>>> That generally doesn't work because the parameter struct declaration= s >>>> usually change with each new version. In other words, the library's >>>> API is *not* guaranteed binary compatible across versions; we only t= ry >>>> to ensure source-code compatibility. >>> >>> The particular problem with www-client/chromium is caused by >>> >> age-decoders/jpeg/JPEGImageDecoder.cpp> which sort of "hardcodes" in= the >>> compiled binary whether it was compiled against libjpeg-turbo with >>> swizzle support (whatever that is) or not. >>> >>> The real problem here is that with above "no guarantee" of binary >>> compatibility such a solution may be considered legitimate, especiall= y >>> that for e.g. Google Chrome the bundled copy of libjpeg-turbo is alwa= ys >>> used. >>> >>> What do you guys think we should do with this on the Gentoo side?At >> >> always use system libraries > > that doesn't help. the libjpeg turbo peeps themselves have said they d= on't > guarantee compatibility across their own versions. it's forward compatible, which is all we should care about >> and i'm in process of dropping keywording >> from media-libs/jpeg wrt[1] since we have no need for source slot of i= t > > err, no. libjpeg-turbo doesn't provide the older SONAME's like jpeg do= es. > those SLOT's aren't going anywhere (SLOT!=3D0). i said "source slot" which was supposed to mean SLOT=3D"0" alone, the=20 SLOT=3D"62" will still have keywording, SLOT=3D"7" is not used anything i= n=20 tree but can still have the keywording (unintresting to this topic) > history has shown that the canonical version stays around while the > derivatives come and go. and the ones before never had this level of people behind it, and=20 projects where people get paid to get it working, like fedora > so until the seemingly braindead ABI policies of > libjpeg-turbo can get sorted out, i don't think we can drop KEYWORDS on= SLOT=3D0 > jpeg. the only thing that's really broken is building against libjpeg-turbo,=20 and then switching to ijg's jpeg without rebuilding the package and downgrading of libjpeg-turbo both of which are not worth of supporting