Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

[Michał Górny]

On Thu, 19 Jan 2012 10:19:27 +0100
""Paweł Hajdan, Jr."" <phajdan.jr@g.o> 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=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/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