List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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
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 here
> 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
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
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
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