libjpeg vs. libjpeg-turbo

Clemens Lang cal at macports.org
Mon May 25 03:15:41 PDT 2015



----- On 25 May, 2015, at 11:48, René J.V. Bertin rjvbertin at gmail.com wrote:

> I don't recall having seen anything about libjpeg and forward compatibility.
> It's not surprising that libjpeg.9.dylib cannot be replaced by libjpeg.8.dylib,
> but what about the other way around? (Concretely, what happens with
> applications built against libjpeg.8.dylib when that library becomes a symlink
> to  libjpeg.9.dylib?)

There is no such thing as binary compatibility when the library name changes.
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.

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.

Consequently, making libjpeg.8.dylib a symlink to libjpeg.9.dylib is a stupid
idea. Don't do it.


Btw, your idea of putting library version numbers into package names only makes
sense if that gives you the possibility to install different versions of these
libraries side-by-side. That, however, is only possible if you split the files
installed by these ports into separate packages, such as libjpeg8, libjpeg-dev,
etc., because libjpg.dylib -> libjpeg.$num.dylib must be part of a -dev package
that is not always installed. That may be an idea worth considering for MacPorts
now that we provide a lot of precompiled binaries, but it needs a huge overhaul
of our ports tree to work correctly.

-- 
Clemens Lang


More information about the macports-users mailing list