My institution has recently upgraded to Ubuntu 18.04 and to Mathematica 11.3 and I'm guessing various other packages have been upgraded alongside this. I have the latest MaTeX version downloaded (1.7.4) and the GhostScript version installed is 9.25 (as ascertained by running gs --version, also gs is in the usual place: /usr/bin/gs). However when I run


It tells me

/usr/bin/gs is either not working or is not a command line version of Ghostscript
Please configure Ghostscript using ConfigureMaTeX["Ghostscript"->"path to gs executable"]

Upon running


I get the same error. gs is a command line version, so I don't know what the problem is.

  • 3
    $\begingroup$ Please download the troubleshooting notebook (linked at the end of this page), evaluate it, and e-mail it to me. Instructions are within the notebook. $\endgroup$
    – Szabolcs
    Oct 12, 2018 at 16:53
  • $\begingroup$ I went ahead with the answer before receiving your response e-mail as I need to log off for today. Let me know if you think my hypothesis is incorrect. $\endgroup$
    – Szabolcs
    Oct 12, 2018 at 18:01

1 Answer 1


tl;dr MaTeX 1.7.0 and later do not have this issue. Restarting Mathematica after upgrading will fix the problem.

After receiving the troubleshooting notebook from OP in e-mail, I believe this is what happened:

The problem encountered by the OP only affects MaTeX versions earlier than 1.7.0. The OP probably had such an old version. After upgrading the paclet to 1.7.4, the OP immediately tried to re-load MaTeX with Needs instead of Get, without restarting Mathematica. Needs however does not re-load an already loaded package. The package was updated only on the disk, but not in-memory, thus the issue persisted.

Using Get, or just quitting the kernel, fixes it.

I have updated the instruction to suggest using Get instead of Needs. Hopefully, others won't fall in the same trap.

What exactly fails in MaTeX on Linux systems prior to version 1.7.0?

MaTeX uses RunProcess to call Ghostscript and pdflatex. Both depend on zlib. Mathematica ships an older version of zlib on Linux, and its startup script sets LD_LIBRARY_PATH to point to Mathematica's own library directory where this zlib is located. This means that not only Mathematica, but also any other program launched by Mathematica will try to use this old zlib. However, programs shipped with recent Linux distributions require a newer zlib, and will fail when dynamically linking against Mathematica's copy.

This is what happens:

In[]:= RunProcess[{"/usr/bin/gs", "--version"}]

Out[]= <|"ExitCode" -> 1, "StandardOutput" -> "", 
 "StandardError" -> 
     "/usr/bin/gs: /opt/mathematica/SystemFiles/Libraries/Linux-x86-64/libz.so.1: \
      version `ZLIB_1.2.9' not found (required by /usr/lib/x86_64-linux-gnu/libpng16.so.16)"|>

The workaround is to temporarily clear LD_LIBRARY_PATH before running these programs. This is best achieved with the ProcessEnvironment option of RunProcess: preserve everything in the environment (GetEnvironment), except LD_LIBRARY_PATH.

Unlike SetEnvironment, this method is safe. SetEnvironment would affect all programs launched by Mathematica, including some of its own components.

  • $\begingroup$ Thanks for the detailed answer! Most impressive was that you diagnosed the version change without me doing much. $\endgroup$
    – bjorne
    Oct 12, 2018 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.