[tlbuild] Building without X11?

[Mojca Miklavec]

Hi,

I have a slightly different question from the one I initially wrote, actually.

If I install (non-legacy, that that will end up in MacTeX) binaries on
10.13, I get:

> mf -version
dyld: Library not loaded: /opt/X11/lib/libSM.6.dylib
  Referenced from: /opt/tl/2018/bin/x86_64-darwin/mf
  Reason: image not found
Abort trap: 6

> mflua-nowin -version
dyld: Library not loaded: /opt/X11/lib/libSM.6.dylib
  Referenced from: /opt/tl/2018/bin/x86_64-darwin/mflua-nowin
  Reason: image not found
Abort trap: 6

etc. But mf-nowin works fine despite "otool -L mflua-nowin" listing a
bunch of X11 libraries (I wonder how that is even possible) and mflua
format says "disabled", whatever that means.

>From that I also suspect that mflua-nowin has a slightly broken build
configuration files as it behaves different from metafont itself. (I
still don't understand why those X11 libraries end up showing in
mf-nowin, but that's yet another thing which I would also consider
semi-weird or somewhat broken.)

While I don't care about pdfopen/pdfclose (I would never attempt to
use it), a defunct metafont might have some more serious consequences.
I tried to figure out if this could lead to any troubles when running
the installer, but I wasn't sure how to reliably check.

The
    fmtutil-sys --byfmt mf
command uses mf-nowin which works correctly, while
    fmtutil-sys --byfmt mflua
says
    fmtutil [INFO]: did not find entry for byfmt=mflua, skipped
    fmtutil [INFO]: Disabled formats: 1
    fmtutil [INFO]: Not selected formats: 8
    fmtutil [INFO]: Total formats: 9
I didn't install the full scheme though and I'm no longer compiling
any of those documents where metafont would be called all the time,
telling me that it's unable to find some fonts (but I guess it uses
mf-nowin, so one should be on the safe side).

Mojca

On 31 March 2018 at 18:29, Mojca Miklavec wrote:
> Hi,
>
> My darwinlegacy binaries in subversion are not quite ok yet (the
> libc++ library that I compiled against is too new and the binaries
> don't work on all OS versions inbetween).
>
> I now tried a slightly different approach which seems to work on all
> binaries that currently fail, but it led to troubles with the X11
> library. That library is only used in metafont (but in multiple
> places: inimf, mf, mflua, mflua-nowin, mfluajit, mfluajit-nowin). The
> only two other places where X11 is used are:
> - pdfopen/pdfclose
> - xdvi-xaw
>
> I wanted to check what pdfopen actually does on macOS, only to figure
> out that the binary is broken anyway unless the user explicitly
> installs X11 (the same problem with both mine and Dick's binaries):
>
>> ./pdfopen
> dyld: Library not loaded: /opt/X11/lib/libX11.6.dylib
>   Referenced from: /current/dir/./pdfopen
>   Reason: image not found
> Abort trap: 6
>
> I would usually ignore the problem, but I'm already stuck at the build
> step because tests like these fail on the test system that I'm using:
>     FAIL: mftraptest.test
>     FAIL: mfluadir/mfluatraptest.test
>     FAIL: mfluajitdir/mfluajittraptest.test
>
> I know how to work around these issues, but I have a better question:
> is it OK if I simply build everything with --without-x on
> darwinlegacy?
>
> As a consequence this removes pdfopen, pdfclose, xdvi-xaw, but I
> question their usefulness on macOS anyway (then again, I don't know, I
> never really used them).
>
> I now have a set of binaries compiled against 10.7 SDK with
> compatibility set to 10.6: that should work on 10.7 (what's currently
> in svn doesn't work) and most likely work with 10.6, or at least all
> the tests pass and my basic experiments passed. I could alternatively
> try to mix-and-match 10.6 and 10.7 SDKs (inject libc++ from 10.7 into
> 10.6), but I'm afraid that libc++ will be automatically updated on
> some subsequent update without me noticing.
>
> Mojca