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
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users
