On Wednesday May 20 2015 12:11:08 Clemens Lang wrote:
> Yes, we would have to revbump all dependents of the jpeg port if we do
> this. Since it is unlikely that mozjpeg and libjpeg-turbo will ever
> implement the changes to become compatible with libjpeg.9.dylib there is
> no way to avoid the rebuild for this kind of switch.
There are (probably) a number of huge ports that would have to be rebuilt,
among the already huge number.
Supposing no one uses the new features from libjpeg, there are 2 (temporary)
options that can be used during a grace period:
1- symlink libjpeg.9.dylib to libjpeg.8.dylib
2- rename/relabel libjpeg.8.dylib to libjpeg.9.dylib
The latter would make libjpeg and libjpeg-turbo/mozjpeg interchangeable, but
the former would have the advantage that anything built against this fake
libjpeg.9.dylib would in fact register libjpeg.8.dylib in its "rpath".
I know it's a hack, but I simply cannot condone an approach that would force
anyone to accept the rebuilding consequences of doing things properly,
depending myself on my ports for productivity.
As a related question: libjpeg-turbo depends on port:nasm, but I cannot get it
NOT to insist on reinstalling nasm+universal, not even using a
path:${prefix}/bin/nasm style dependency. How to get around that? Evidently
there is no point in installing nasm +universal just to build something
+universal ...
R.
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users
