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 1RnoS1-0003sf-8r for garchives@archives.gentoo.org; Thu, 19 Jan 2012 09:38:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 85677E0833; Thu, 19 Jan 2012 09:38:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 85E66E06BA for ; Thu, 19 Jan 2012 09:37:55 +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 942461B4003 for ; Thu, 19 Jan 2012 09:37:54 +0000 (UTC) Message-ID: <4F17E3EF.2070706@gentoo.org> Date: Thu, 19 Jan 2012 11:35:43 +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> In-Reply-To: <4F17E01F.6080009@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e0d8f238-8ed5-4d9c-825b-9e094aea8f80 X-Archives-Hash: 23ff8abc39eb1a3587421d2dd27f9c3a 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 in > WebKit, and I learned that despite > > libjpeg-turbo is not necessarily binary compatible with libjpeg, and > even with different versions of itself. > > Here's why. See > > and search for "as a shared library". I'll paste the relevant quote her= e > anyway: > >> While you can build the JPEG library as a shared library if the whim s= trikes >> 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 l= ibrary >> without recompiling the calling applications. That generally doesn't = work >> because the parameter struct declarations usually change with each new >> version. In other words, the library's API is *not* guaranteed binary >> compatible across versions; we only try to ensure source-code compatib= ility. > > The particular problem with www-client/chromium is caused by > > which sort of "hardcodes" in the compiled binary whether it was compile= d > 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, especially > that for e.g. Google Chrome the bundled copy of libjpeg-turbo is always > used. > > What do you guys think we should do with this on the Gentoo side?At always use system libraries and i'm in process of dropping keywording=20 from media-libs/jpeg wrt[1] since we have no need for source slot of it [1] http://bugs.gentoo.org/398909 both providers will be left in the virtual/jpeg, but only libjpeg-turbo=20 will be keyworded (and thus supported), eliminating rest of the issues=20 raised here - Samuli > this moment I've just reverted the mentioned change in > www-client/chromium ebuild, but it's not feasible to keep a local patch > too long (it needs rebasing too often). > > I was thinking about changing SONAMES, which would trigger rebuilds mak= e > things work, but then don't we rely on specific libjpeg SONAMES for > binary-only software to work? Or does such binary-only software just us= e > libjpeg-6b? > > Are there some other solutions we could apply on the Gentoo side? The > main point here is that Chromium upstream considers > > a legitimate change, and based on the referenced > > disclaimer about no guarantee of binary compatibility, I think it makes > sense. >