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.
>From what I've seen, libjpeg9 is not ABI backwards compatible with libjpeg8,
>meaning that something built/linked against jpeg9 won't run with jpeg8, at
>least not when jpeg8 is provided by jpeg-turbo. Probably a moot point anyway,
>because of the libname version number AND the compatibility version recorded
>inside the binary.
> I wondered why libjpeg-turbo would not incorporate libjpeg 9 features, and
> found this article explaining why:
The README shipped with the jpeg-turbo code has a similar explanation.
Apparently the authors are very certain that no one will use the jpeg9 ABI even
if that's just because of updating for updating's sake as happened here.
Because even if you don't agree with the additional functionality provided, you
can emulate the ABI with the new functions being stubs, or so I'd assume.
Maybe there's a lesson to be learned here: when much-used fundamental libraries
change their ABI, follow the lead of what happens in Linux land Probably not
what cutting-edge distributions like Arch or Gentoo do, but rather the ones
with longer term support.
As a side-note: thinking (100% wishfully, I'm aware) about this, and the
productivity issues that can come with being too cutting-edge, I find it a pity
that MacPorts (nor any of its brethren AFAIK) provides different updating
schemes that would allow the user to select between always having the latest
version of everything, and something that provides more long-term stability.
But then I'm not even sure if Debian/Ubuntu really allow the user to configure
such a choice (despite having an urgency indicator on each package version).
R.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
