On Mon, 26 Nov 2018 at 10:36, Dr M J Carter wrote: > On Sat, Nov 24, 2018 at 11:58:16AM +0000, Christopher Jones wrote: > > > Note that the version of Xquartz from [2]www.xquartz.com is in fact > > just a packaging of the MacPorts version ! In fact, the maintainer > > of the Xquartz releases has stated that they may well no longer make > > releases there, and only maintain the MacPorts provided version (via > > the xorg-server port) going forward. > > That's going to prove interesting for those of us using MacTeX: its > copy of gs-X11 seems to request and require libraries in /opt/X11 at > runtime, not just at setup.
There's no easy solution to this. The only workaround would be using @rpath trickery to allow using a dylib from a different path (but even then you could only perhaps check /opt/local/lib, not any other random prefix that MacPorts might be installed under). Or load the library at runtime. But if you do require X11, you need to get it from somewhere, and defaulting to the version from MacPorts for ghoscript in MacTeX would be utterly strange. MacPorts ships with its own version of ghostscript (which doesn't need /opt/X11), and there's no need to install ghostscript with MacTeX (I never do) if you have MacPorts installed already. Additionally, when I built the binaries for legacy macs (for any system that's no longer supported by Apple; shipped with TeX Live by default, but not with MacTeX which no longer works there), I tried to make sure to not support X11 in any way, so you don't get any X11 bindings with metafont for example. Precisely because I hate to have failing binaries just because the user did not install /opt/X11. > (In our setups, /usr/local/bin comes > before /opt/local/bin, for reasons I can be tedious about on request, > so MacTeX's gs preempts MacPorts's.) Mojca
