libjpeg vs. libjpeg-turbo

[René J.V. Bertin]

On Monday May 25 2015 12:15:41 Clemens Lang wrote:

> There is no such thing as binary compatibility when the library name changes.

                           ^ guaranteed

> That's the whole point of changing the library name. If you only add new
> interfaces and preserve binary compatibility, the library name wouldn't change.

I don't think so, no. Because then you suggest backwards ABI compatibility, which evidently wont be the case, not unless the new stuff is added via Qt-style d-pointers.

> You can try it, but if upstream knows what it's doing w.r.t. library version
> numbering – and it seems that's the case here – all you'll see is a crash or
> failure to load.

I've been wanting to add a jpeg8 subport anyway, for comparison. Mind you, I'm not saying that I expect anything but failure, but in the end I didn't see the point in doing the necessary tweaking of the library compatibility version. Those pesky version numbers that I don't know how to change other than by relinking the library...

I did discover one obstacle to swapping libjpeg.8.dylib from port:jpeg and port:libjpeg-turbo: the former sets compatibility version 13.0.0, the latter version 9.0.0 . BTW, libjpeg.9.dylib has compat. version 11.0.0 ... so I'm not sure to what extent upstream really know what they're doing with OS X specific library versioning ...
So if libjpeg is to be maintained as a 3rd alternative a patch will be required to change the compatibility and current version that is stored in libjpeg.8.dylib .

mozjpeg does have the same compat. version info as libjpeg-turbo, but that is maybe only because they're a spin-off from that project.

R