Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Odd error from latexmk

1,945 views
Skip to first unread message

Peter Flynn

unread,
Mar 19, 2016, 6:32:21 PM3/19/16
to
I am using latexmk -f -gg -xelatex -bibtex to process a very large and
complex document, and it's working just fine with one exception: each
run ends with this:

> Latexmk: Errors, so I did not complete making targets
> Collected error summary (may duplicate other messages):
> pdflatex: Command for 'pdflatex' gave return code 256
> Latexmk: Use the -f option to force complete processing,
> unless error was exceeding maximum runs of latex/pdflatex.
> Makefile:21: recipe for target 'pdf' failed
> make: *** [pdf] Error 12

There were no errors in the processing (all references resolved, no
missing images, etc), but most importantly, I am not using pdflatex, I'm
using xelatex. The workflow doesn't go anywhere near pdflatex.

I can't find anywhere that the code 256 is defined. Is this Perl's
longword return value, implying a xelatex exit of 1, or something else?
xelatex clearly executed just fine.

And what is Error 12?

There are several questions about this on Stack, Nabble, etc, but none
of them provide an answer.

///Peter

Herb Schulz

unread,
Mar 20, 2016, 7:48:28 AM3/20/16
to
On Mar 19, 2016, Peter Flynn wrote
(in article <dl62bh...@mid.individual.net>):
Howdy,

Latexmk uses `pdflatex' as a generic name for the processor you chose,
xelatex in this case, so don't worry about it using that name.

Check to see how many runs of `pdflatex' there are. Latexmk will execute up
to 6 runs while still finding that files have changed before quitting; i.e.,
before it decides it's in an infinite loop.

Do any of your included packages produce files that change on every run?

Good Luck,
Herb Schulz


Peter Flynn

unread,
Mar 21, 2016, 6:00:40 PM3/21/16
to
OK, thanks.

> Check to see how many runs of `pdflatex' there are. Latexmk will execute up
> to 6 runs while still finding that files have changed before quitting; i.e.,
> before it decides it's in an infinite loop.

I looked through the Emacs buffer but there wasn't any evidence of
changes. The process ran xelatex, biber, xelatex, makeindex, xelatex and
the xelatex again, and the trace ends with the PDF being made, and when
I open it, it's all correct.

> Do any of your included packages produce files that change on every run?

Aha. The .tex file carries the .bib file inside it in a VerbatimOut
block, so the .bib is freshly regenerated every run of XeLaTeX (the idea
being portability: you only need to send someone one file; they can't
"forget" to send the .bib as well as the .tex).

Seemed like a good idea at the time :-) This is a legacy of the original
XSLT transformation which was working so well I had forgotten about it.
Moving it to a result-document in XSLT2 fixed the problem.

Thank you!

///Peter

Herb Schulz

unread,
Mar 21, 2016, 9:38:24 PM3/21/16
to
On Mar 21, 2016, Peter Flynn wrote
(in article <dlb982...@mid.individual.net>):
Howdy,

How old is the latexmk you are using? For quite a while now latexmk keeps
track of md5 sums for generated files and uses that to decide if a file's
contents have really changed even if the dates don't match. Unless you are
entering the date/time in that file, so there really is a change each time,
there shouldn't be a problem; I just tested it out with a .bib file created
with the filecontents environment. The latest version of latexmk even has a
way to get around that sort of problem.

Good Luck,
Herb Schulz


Peter Flynn

unread,
Mar 22, 2016, 4:10:07 PM3/22/16
to
$ latexmk -version

Latexmk, John Collins, 1 January 2015. Version 4.41
$

But in fact generating the .bib file in parallel with the .tex file
(instead of relying on it being emitted by LaTeX during processing) is a
much better idea, so it's all working fine now, thanks.

///Peter

Herb Schulz

unread,
Mar 22, 2016, 6:54:33 PM3/22/16
to
On Mar 22, 2016, Peter Flynn wrote
(in article <dldn4q...@mid.individual.net>):
Howdy,

I have never used a VerbatimOut block but I have used a filecontents
environment and don't have a problem with latexmk. The filecontents
environment checks to see if the file already exists and won't overwrite it
if it does. Try

\begin{filecontents}{filename.ext}
Put the contents here
\end{filecontents}

BEFORE the \documentclass command. The filecontents environment places a few
comment lines (leading with %) at the top of the file. There is also the
starred version which leaves those lines out.

Good Luck,
Herb Schulz


0 new messages