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 1RnvHz-0002Ia-U5 for garchives@archives.gentoo.org; Thu, 19 Jan 2012 16:56:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4785AE0914; Thu, 19 Jan 2012 16:56:31 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C05F2E088A for ; Thu, 19 Jan 2012 16:56:06 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 374251B400B for ; Thu, 19 Jan 2012 16:56:06 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility Date: Thu, 19 Jan 2012 11:56:05 -0500 User-Agent: KMail/1.13.7 (Linux/3.2.0; KDE/4.6.5; x86_64; ; ) References: <4F17E01F.6080009@gentoo.org> <4F17E3EF.2070706@gentoo.org> In-Reply-To: <4F17E3EF.2070706@gentoo.org> 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 Content-Type: multipart/signed; boundary="nextPart1894296.0Jbud61KOF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201201191156.06226.vapier@gentoo.org> X-Archives-Salt: afa1645c-fb55-4ee6-85eb-2bdf03c13fa2 X-Archives-Hash: 81b113190aadceb3f14df77f2bb00f5a --nextPart1894296.0Jbud61KOF Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 in > > WebKit, and I learned that despite > > > e6.xml> libjpeg-turbo is not necessarily binary compatible with libjpeg, > > and even with different versions of itself. > >=20 > > Here's why. See > > > peg.txt?revision=3D299&view=3Dmarkup> and search for "as a shared libra= ry". > > I'll paste the relevant quote here > >=20 > > 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.=20 > >> 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 compatibility. > >=20 > > 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. > >=20 > > 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. > >=20 > > What do you guys think we should do with this on the Gentoo side?At >=20 > always use system libraries that doesn't help. the libjpeg turbo peeps themselves have said they don't= =20 guarantee compatibility across their own versions. > and i'm in process of dropping keywording > from media-libs/jpeg wrt[1] since we have no need for source slot of it err, no. libjpeg-turbo doesn't provide the older SONAME's like jpeg does. = =20 those SLOT's aren't going anywhere (SLOT!=3D0). history has shown that the canonical version stays around while the=20 derivatives come and go. so until the seemingly braindead ABI policies of= =20 libjpeg-turbo can get sorted out, i don't think we can drop KEYWORDS on SLO= T=3D0=20 jpeg. =2Dmike --nextPart1894296.0Jbud61KOF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJPGEsmAAoJEEFjO5/oN/WBM0kQAOHNBjQsJ5KLMye69BWm9kk4 5n63oDBl94fOf1gXricaDN9bPzzC+jDUntSFi6GqXidA/RJ6wp+rUc79/ZzJawTq UuhiIkm++XGIGXb4BZbWWge68FXszVRF8DQ5mlkqD2cN3Xex70xzsV1DeLu8JvBA lbejXtLziGwnUQSdP41K/jfskgQ4Ot81Oq59qznH+VDzfRjDC/mSnPG/seNnj6oM ui7p3p60VN+U287rP5XPLjprQ7Zmfvdopzs839hbJECMROxRNqdxYxY3989XweFM 9oAfL4WeX+siFEYUFPrlZLSCckZSAf9P/EE8y61ICpYHi+zcHjdoL/1zNnEqY8M3 JcB8e23Xp4Dsvx/dbkMxLVacLGo3PaQWA8mIPU76wc9YCBl5fTAGh8FxCTjdioc+ bM+ZeWwMi+/l74aLGOmj51aqvXg+fRJTIjagW4/KrATdKOp7YJZ0oBukkbbjIRR3 O80v+kW72KVOCM3v/CJKAqoKdyf2tsXNhYY1oTqcpxI92Kz12R997UD6yYOUm29B YmXFq5uKoU0a4n1myWaxpAZ0qzbE3TRT/w1P5kwW9YI5LdhQOPOEYRY5AzKSCW59 Obwb6elDyegQmEXHgaKLXxqLKJclUuZr//j8YKf17Ms6A2fvqo/OvDl6VeKa8oCQ t0xxCh5mvlszgayyceas =vaC/ -----END PGP SIGNATURE----- --nextPart1894296.0Jbud61KOF--