On 1/19/12 10:45 AM, Michał Górny wrote: > Hmm, does this mean the ABI differs on runtime compilation options?
No, at least I'm not aware of such a thing. I'd sum it up as "libjpeg-turbo is not binary-compatible with libjpeg and also with a different version of itself, and is not supposed to be". > SONAME should be changed with new versions, not options. If upstream > does allow things like that, that's bad. I think upstream keeps the SONAME at "libjpeg.so.8" . And as indicated by <https://bugs.gentoo.org/show_bug.cgi?id=393471#c3> and the next comment, libjpeg-turbo-1.1.1 and libjpeg-1.1.90 shouldn't have the same SONAME (they're not binary compatible wrt JCS extensions Chromium uses). > If chromium uses that, it's even worse. That's what I initially thought, but the "as a shared library" paragraph I quoted from <http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299&view=markup> strongly suggests it's legitimate to do what they've done. > 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. I think OpenBSD also has its own SONAME cycles, which is not necessarily too bad (except for binary-only software). In Gentoo, we also have our own SONAME for V8 JavaScript engine (upstream only provides infrastructure for setting SONAME, i.e. a build system switch).
signature.asc
Description: OpenPGP digital signature
