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ł Hajdan, Jr." wrote:
While dealing with<https://bugs.gentoo.org/show_bug.cgi?id=393471> I
started discussing with developers working on libjpeg-turbo support in
WebKit, and I learned that despite
<http://archives.gentoo.org/gentoo-dev/msg_e67bedf25dd178ec09a325a1220724
e6.xml> libjpeg-turbo is not necessarily binary compatible with libjpeg,
and even with different versions of itself.
Here's why. See
<http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libj
peg.txt?revision=299&view=markup> and search for "as a shared library".
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 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.
The particular problem with www-client/chromium is caused by
<http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/im
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, 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
that doesn't help. the libjpeg turbo peeps themselves have said they don'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 it
err, no. libjpeg-turbo doesn't provide the older SONAME's like jpeg does.
those SLOT's aren't going anywhere (SLOT!=0).
i said "source slot" which was supposed to mean SLOT="0" alone, the
SLOT="62" will still have keywording, SLOT="7" is not used anything in
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
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=0
jpeg.
the only thing that's really broken is building against libjpeg-turbo,
and then switching to ijg's jpeg without rebuilding the package
and downgrading of libjpeg-turbo
both of which are not worth of supporting
