| 1 |
On 1/19/12 10:45 AM, Michał Górny wrote: |
| 2 |
> Hmm, does this mean the ABI differs on runtime compilation options? |
| 3 |
|
| 4 |
No, at least I'm not aware of such a thing. |
| 5 |
|
| 6 |
I'd sum it up as "libjpeg-turbo is not binary-compatible with libjpeg |
| 7 |
and also with a different version of itself, and is not supposed to be". |
| 8 |
|
| 9 |
> SONAME should be changed with new versions, not options. If upstream |
| 10 |
> does allow things like that, that's bad. |
| 11 |
|
| 12 |
I think upstream keeps the SONAME at "libjpeg.so.8" . And as indicated |
| 13 |
by <https://bugs.gentoo.org/show_bug.cgi?id=393471#c3> and the next |
| 14 |
comment, libjpeg-turbo-1.1.1 and libjpeg-1.1.90 shouldn't have the same |
| 15 |
SONAME (they're not binary compatible wrt JCS extensions Chromium uses). |
| 16 |
|
| 17 |
> If chromium uses that, it's even worse. |
| 18 |
|
| 19 |
That's what I initially thought, but the "as a shared library" paragraph |
| 20 |
I quoted from |
| 21 |
<http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299&view=markup> |
| 22 |
strongly suggests it's legitimate to do what they've done. |
| 23 |
|
| 24 |
> But it should be upstream SONAME change (considering they do change |
| 25 |
> SONAMEs when releasing binary-incompatible versions); we don't really |
| 26 |
> want to go the Debian way, keeping our own SONAME cycles. |
| 27 |
|
| 28 |
I think OpenBSD also has its own SONAME cycles, which is not necessarily |
| 29 |
too bad (except for binary-only software). In Gentoo, we also have our |
| 30 |
own SONAME for V8 JavaScript engine (upstream only provides |
| 31 |
infrastructure for setting SONAME, i.e. a build system switch). |
Archives