libjpeg vs. libjpeg-turbo

René J.V. Bertin rjvbertin at
Fri May 22 01:57:07 PDT 2015

On Thursday May 21 2015 22:49:21 Ryan Schmidt wrote:

Taking this to macports-dev ...

>> This could become an issue on PPC and older versions. Who can test, whether
>> current libjpeg-turbo builds?
>I can, in a day or two.

I can upload an updated portfile that provides the latest libjpeg-turbo, if you want, tested to build +universal.
The port claims to support only Intel CPUs, so it might be necessary to provide it with a fall-back to libjpeg 8 for PPC systems.
In that light, it might also be a good idea to follow the Debian/Ubuntu lead on versioning, and prepend the major compatibility version to the port version so it becomes easier to compare them. Supposing MacPorts supports a colon in the version:
libjpeg: 9:9a
libjpeg-turbo: 8:1.4.0
mozjpeg: 8:3.0

>> I'd skip that. If it works with jpeg, it's supposed to work with libjpeg-turbo
>> (mind it being a drop-in replacement.)

First results here support that, but I haven't rebuilt many ports just yet.

> I'd be surprised to see any software use jpeg 9 features.

Until it starts be used, and then what? That eventuality will have to be taken into account, and I think it'd be good to prepare a solution to allow co-existence of libjpeg9 with libjpeg8 alternatives, maybe even as the first step in this whole adventure.
Why not modify port:jpeg so that it installs in a different way, where it wouldn't be found be automatic search routines in build systems, say in ${prefix}/libexec/libjpeg . Ports that require jpeg9 can undoubtedly use a configure option to find the library in there, or absent such an option use a patch.
This approach would also allow to put a symlink to libjpeg.9.dylib in ${prefix}/lib, which would ease the transition from one requiring a full rebuild of all dependents to one where existing binaries continue to function and will move to jpeg-turbo/mozjpeg at their next update/rebuild. All while providing an existing escape route if ever there are compatibility issues.
Shouldn't be hard to implement, and I'd be happy to propose a draft.

More information about the macports-dev mailing list