# TikZ Externalize & Linegoal conflict?

I'm new to stackexchange, and did not find any information about this issue. I encounter an error whenever I try to use the TikZ's externalize along with (unrelated to TikZ pictures-) \linegoal. My engine is MikTeX on Win7 with TeXstudio. As soon as the linegoal package is used along with externalize, linegoal throws an error:

! Package linegoal Error: \linegoal does not work if output file are disabled
(linegoal) please check the value of \if@filesw!.


A MWE is:

\documentclass[11pt]{article}
\usepackage{linegoal}
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize
\begin{document}
\begin{tikzpicture}
\draw (0,0) -- (1,1);
\end{tikzpicture}

\parbox[t]{\linegoal}{test}
\end{document}


Does anyone have an idea on how to solve that?

-
– Peter Grill Sep 29 '12 at 22:17

The external library explicitly suppresses the generation of auxiliary LaTeX files (because their generation is not thread-safe).

It uses \nofiles to disable the handling of .aux files while it generates external graphics. It will use custom functionality to allow auxiliary data like \label and \ref.

Thus, the short answer is: sorry, these two packages are incompatible.

That said, there may be more-or-less reliable work-arounds. It is like opening a warranty seal...

What you can try is to temporarily hack \nofiles such that tikz believes that it disabled them although it did not:

\let\oldnofiles=\nofiles
\let\nofiles=\relax
\tikzexternalize
\let\nofiles=\oldnofiles


with this hack, your minimal example compiles. However, it may fail utterly. Perhaps you should use \tikzexternalize[mode=list and make] or something like that - the default mode=convert with system call is doomed to fail eventually due to unavoidable race conditions around these aux files.

-
The workaround works perfectly for my document! Thanks very much for the answer. – user19343 Oct 13 '12 at 11:44