Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On 1/19/12 6:42 PM, Samuli Suominen wrote: a) changing the virtual/jpeg dependency to=libjpeg-turbo-... will be done soon as 1.2.0 is released and stabilized, i'd like to skip 1.1.90 Sounds good to me. a) is fine, preventing any downgrades. a fatal check, like glibc and qt4 has to prevent downgrading is an option too, but a bit overkill imho Agreed, in my opinion such a check would be a bad idea. People might have reasons to temporarily downgrade libjpeg-turbo. An elog notice could be worthwhile though. signature.asc Description: OpenPGP digital signature
[gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
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_e67bedf25dd178ec09a325a1220724e6.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/libjpeg.txt?revision=299view=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/image-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 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 make 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 use libjpeg-6b? Are there some other solutions we could apply on the Gentoo side? The main point here is that Chromium upstream considers http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp a legitimate change, and based on the referenced http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299view=markup disclaimer about no guarantee of binary compatibility, I think it makes sense. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On 01/19/2012 11:19 AM, Paweł Hajdan, Jr. wrote: While dealing withhttps://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_e67bedf25dd178ec09a325a1220724e6.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/libjpeg.txt?revision=299view=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/image-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 and i'm in process of dropping keywording 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 will be keyworded (and thus supported), eliminating rest of the issues 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 make 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 use libjpeg-6b? Are there some other solutions we could apply on the Gentoo side? The main point here is that Chromium upstream considers http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp a legitimate change, and based on the referenced http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299view=markup disclaimer about no guarantee of binary compatibility, I think it makes sense.
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On Thu, 19 Jan 2012 10:19:27 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org 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_e67bedf25dd178ec09a325a1220724e6.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/libjpeg.txt?revision=299view=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/image-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 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 make 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 use libjpeg-6b? Hmm, does this mean the ABI differs on runtime compilation options? SONAME should be changed with new versions, not options. If upstream does allow things like that, that's bad. If chromium uses that, it's even worse. I'd go with the simplest solution which is either enabling the particular configure option unconditionally or disabling it. If possible -- synced with SONAME change. But it should be upstream SONAME change (considering they do change SONAMEs when releasing binary-incompatible versions); we don't really want to go the Debian way, keeping our own SONAME cycles. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On Thursday 19 January 2012 04:35:43 Samuli Suominen wrote: On 01/19/2012 11:19 AM, Paweł Hajdan, Jr. wrote: While dealing withhttps://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=299view=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. 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). history has shown that the canonical version stays around while the derivatives come and go. 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. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On 1/19/12 6:02 PM, Samuli Suominen wrote: On 01/19/2012 06:56 PM, Mike Frysinger wrote: 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 Just a note: that'd require me to DEPEND on a recent enough version of libjpeg-turbo in the www-client/chromium ebuild, which would mean either: a) changing the virtual/jpeg dependency to =libjpeg-turbo-... b) adding a versioned virtual/jpeg to require a recent enough libjpeg-turbo (but then what about libjpeg versions - it can easily become complicated) c) similar to a) but also adding || ( =libjpeg-turbo-... libjpeg ) With proper SONAMEs in libjpeg-turbo that would be a non-issue (bump the SONAME on incompatible change, revdep-rebuild does the rest). the only thing that's really broken is building against libjpeg-turbo, and then switching to ijg's jpeg without rebuilding the package I'm fine with not supporting that, provided keywords for libjpeg are dropped (except the 62 slot iirc). and downgrading of libjpeg-turbo I think this one should just work, or at least not allow obvious mistakes. See my a) b) c) notes above in this e-mail for possible solutions and ideal SONAME. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On 01/19/2012 07:16 PM, Paweł Hajdan, Jr. wrote: On 1/19/12 6:02 PM, Samuli Suominen wrote: On 01/19/2012 06:56 PM, Mike Frysinger wrote: 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 Just a note: that'd require me to DEPEND on a recent enough version of libjpeg-turbo in the www-client/chromium ebuild, which would mean either: a) changing the virtual/jpeg dependency to=libjpeg-turbo-... will be done soon as 1.2.0 is released and stabilized, i'd like to skip 1.1.90 and downgrading of libjpeg-turbo I think this one should just work, or at least not allow obvious mistakes. See my a) b) c) notes above in this e-mail for possible solutions and ideal SONAME. a) is fine, preventing any downgrades. a fatal check, like glibc and qt4 has to prevent downgrading is an option too, but a bit overkill imho