Manual:Enable TeX/problems

Many users reported problems with installation of texvc.

There are 2 groups of such problems:
 * it doesn't work even from the command line
 * it does work from the command line, but not from PHP

Command line
You need to install ImageMagick with PS support (ImageMagick is not nice to compile by hand, get binaries if you can) or Ghostscript, Latex, dvips (part of Latex).

If you do, check permissions.

Comment file unlinking out in render.ml to see what's going on better.

strace or equivalent utility may be useful for tracing command executions.

You need GNU make to compile texvc. On some non-Linux Unices it's under name gmake instead of make.

PHP
Check that it works form the command line. If not, see the previous section.

The environment under Apache/PHP is different that the shell. Typical problems:
 * user may be different, check permissions
 * PATH variable may be different, use absolute paths in render.ml if you can't fix it
 * you may be in a jail/chroot

Error : Failed to parse (Missing texvc executable)
Failed to parse (Missing texvc executable); please see math/README to configure.)

That error is returned in response to this test:

if( function_exists( 'is_executable' ) && !is_executable( $wgTexvc ) ) { return $this->_error( 'math_notexvc' ); }

So, if you're getting the error there are a few possibilities:
 * $wgTexvc is set to the wrong path
 * the file doesn't exist
 * the file isn't executable by the web server according to permissions
 * some weird PHP restriction is preventing you from accessing the file

You should check into all of these possibilities.

Another possibility is that you wrote that wiki page before compiling texvc, and haven't rerendered any math since. Remember that page renderings are aggressively cached; run your tests in a preview and try varying texts.

Someone managed to fix it by "by uninstalling the Suse native apache, mysql, php, and mediawiki, and replacing them with xampp and mediawiki tarball.". He has no idea why it worked.

If you are running AppArmor (Suse 10 does this by default) add texvc to the AppArmor Profile, this can most easily be done via yast2. Be sure to enable execute rights ("x") in the editor, otherwise AppArmor will block the execution of texvc. If AppArmor is blocking an application usually it is logged in /var/log/apparmor.

safe_mode
If you use PHP safe_mode, you will have to patch includes/Math.php and use a wrapper script for texvc.

For more details, see: http://xylofaan.ulyssis.org/patch/mediawiki/math_safe_mode/

render.ml
render.ml is the only file that contains commands executed by texvc. If you need to change command names or their paths, edit that file. It should be straightforward.

Which latex, dvips, convert ...
A universal fix is to change render.ml to use the env shell command in each of the let cmd_ ... =</tt> statements. To verify and see which commands are returned by the env</tt> command just try, for example, at the command prompt $ which latex</tt>. let cmd_dvips tmpprefix = "env dvips ... let cmd_latex tmpprefix = "env latex ... let cmd_convert tmpprefix finalpath = "env convert ...

Then run make</tt> in the math directory again. You may need to restart Apache.

Permissions problem
latex</tt> doesn't have an option to specify an output directory, so it just places the output files (.log, .aux, .dvi) into the current directory. The render.ml</tt> file line if Util.run_in_other_directory tmppath (cmd_latex tmpprefix0) != 0 handles this by calling the function run_in_other_directory</tt> defined in util.ml</tt>. Function run_in_other_directory</tt> attempts to save the current directory, change directory to the proper output (temp) directory, call latex, then change back to the previous current directory. To get the current directory, a function called Sys.getcwd</tt> is used, but if there are not sufficient permissions to read the directory (all parent directories back to the root must be readable by the user running texvc</tt>), then texvc</tt> just quits. There will be a .tex file in the temp directory, but no .dvi or other files. One way to fix this is to replace the above line of render.ml</tt> with these two lines: Sys.chdir tmppath; if Sys.command (cmd_latex tmpprefix) != 0 (Recompile texvc</tt>.) This will change the current directory, then run latex</tt>. Changing back to the original directory doesn't appear to be necessary.

Installing tetex
Rather than using a global directory, e.g. /opt/local/bin/</tt>, for installation or symlinking, your latex installation is more likely able to find its configuration files if you install everything in the <tt>teTeX</tt> directory and referencing the binaries directly.

For example, configure teTeX to install into <tt>/home/wiki/local/teTeX/</tt> with <tt>./configure --prefix=/home/wiki/local/teTeX/</tt>. Then, rather than symlinking them, reference them directly from <tt>render.ml</tt>, i.e. let cmd_dvips tmpprefix = "/home/wiki/local/teTeX/bin/x86-unknown-linux-gnu/dvips ... let cmd_latex tmpprefix = "/home/wiki/local/teTeX/bin/x86-unknown-linux-gnu/latex ...

In this way, the <tt>latex</tt> and <tt>dvips</tt> executables know their own directory and will search the immediate parents for the relevent teTeX configuration files. Without them, and without the relevant environment variables, these executables may be unable to find their configuration, and you will get a relatively generic error.

dvipng
GhostScript, ImageMagick and dvips can be replaced by dvipng. It may be easier to configure on some systems, and would be much faster. In addition it can do transparent background (full-alpha or all-or-nothing transparency as wished). It can also report the baseline position if desired.

There is a patch for render.ml to do that, see http://lists.wikimedia.org/pipermail/wikitech-l/2004-April/009596.html

The patch will make an image with a full-alpha transparent background (with dvipng >= 1.6). Remember that there are problems with IE and full-alpha transparency. To use all-or-nothing transparency with dvipng >= 1.6, use '-bg transparent' (all lowercase).

Selinux
On Linux systems with selinux support, such as recent versions of Fedora Core, restrictions enacted by selinux can result in puzzling manifestations. On selinux-enabled systems, it is a good idea to check for records in the selinux log files. On Fedora Core, these are found at. For testing purposes, under Fedora selinux can be disabled interactively with the command:

sudo /usr/sbin/setenforce 0

and re-enabled with the command:

sudo /usr/sbin/setenforce 1

On some systems, for example Fedora Core 7, you can obtain interesting information if you have access to the setroubleshoot browser, a tool which can be accessed from the desktop menus "System" and "Administration". Each time selinux prevents an action from being performed, for example a file access involved in the texvc machinery, it records information that can be viewed in this browser. The browser also describes how to enable the prevented access, typically by performing chcon commands on the specified file. After a sequence of such commands it may be possible to get texvc working properly without disabling selinux.

On one system where texvc was failing to work properly, the shell script was able to create files in the file system normally, but unable to write any contents to these files, where each write request generated an selinux audit log entry of the following form:

type=AVC msg=audit(1165430855.036:398755): avc: denied  { write } for  pid=30145 comm="httpd" name=php-eaccelerator dev=dm-0 ino=16034837 scontext=root:system_r:httpd_t tcontext=system_u:object_r:var_t tclass=dir

MediaWiki detected this error as an empty status response from the texvc shell comamnd, as the contents of the write call to return the status result was denied by selinux. Note that when testing texvc on the command line, the status string written by texvc to stdout does not normally contain a terminating newline, so one some shells the string will not be displayed. To verify that the status string is returning normally, one can run texvc as follows:

./math/texvc arguments > out ls -l out  # view file size vi out     # view status contents

Another option is to run texvc under strace to see that it is functioning normally.

See also: Texvc

An alternative to trying to get texvc to work is to rewrite the Math.php render code to use PHP instead: Texvc PHP Alternative

PaX
PaX is a security feature built into Gentoo Hardened systems designed to add extra memory protection to the kernel. Normally this is a good thing, but it plays havoc with texvc (apparently because texvc relies upon rewriting its own ELF in memory). The solution is to use the paxctl utility to disable MPROTECT on texvc and associated executables:

sudo paxctl -m math/texvc math/texvc_test math/texvc_tex

This should resolve the dreaded "error while loading shared libraries: cannot make segment writable for relocation: Permission denied" problem.