How should I deal with packages that require FFI external libraries?

[Bruno Voisin]

> Christophe Jorssen wrote:
> 
> 4) Can I compile the library for windows and macos on my linux
> computer? (Sorry, I know it is out of scope.)

> Max Chernoff answered, speaking of FFI:
> 
> There are also support files
> with "arm" in the name, but they're 5 years old so probably Linux only.

> Christophe Jorssen answered:
> 
> Ok. I'll have a look. But mac M{1,2} won't work easely. Got it.

> Then Max Chernoff:
> 
> If the macOS arm ABI is close enough to the Linux arm ABI, it might just
> work. If it doesn't work, you _might_ be able to convince one of the
> MacTeX maintainers to add support, but that wouldn't be distributed
> until TL2024 at the earliest.

Coming in a bit late, and speaking only for the Mac (as one of the MacTeX folks):


- To compile for the Mac, you most likely need two Macs, one with an Intel chip and another with an ARM chip. You compile on both with Xcode (compiler + IDE) or the Command Line Developer Tools (compiler alone), then you combine the two binaries with lipo (part of the developer tools) to create a universal binary.


- Regarding the addition of external libraries into MacTeX, the answer will most certainly be a plain "no".

The future need, owing to the changes in Ghostscript 10.01, to provide for dvisvgm not only libgs (from Ghostscript) but also mutool (from MuPDF), led already to some debate. Finally it was decided to separate libgs from gs and provide it as a separate package with mutool, and see how the community reacts, whether it's worth continuing to provide these additions to basic gs or let the user install them.

The packages are at

https://pages.uoregon.edu/koch/

The concern here is size: mutool adds about 100 MB to the already gigantic MacTeX download. I have colleagues (in a fluid mechanics research department) who complained they did not understand why a TeX install was more than a few hundred magabytes, and asked whether there were alternatives to MacTeX/TeX Live.

Another problem is the complexity of compiling for the Mac, if you want to create a user-friendly install package not requiring the user to bypass os security at install time: you need to sign the software (with a Developer ID), make it a hardened runtime (by explicitly allowing the actions that need to get outside the sandbox, like calling a library signed by another developer or letting the software be affected by environment variables) and notarize it (ie, upload the binary to Apple servers which scan it automatically for potentially harmful actions).

Most likely, if the tendency for TeX packages to require external binaries or libraries persists and develops, the answer (at least on the Mac) will be to require users to install these additions themselves, either by compiling them or using a package manager like MacPorts or Homebrew.


Bruno Voisin

(I'm not on the tex-live list, so I'm more likely to see answers if they're cc'ed to me)