55

I'm getting the following warning:

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

The problem is, it doesn't go away after rerunning (any number of times).

The document in question is over 200 pages long and includes about 30 packages, so it's not really feasible for me to provide a minimal example. But I know my own code pretty well. I can probably fix it if I knew a bit more about the problem. So I want to ask some general questions:

  • How does the "labels changed; rerun" mechanism work, anyway?
  • Is there a common culprit responsible for this problem?
  • How would someone generally go about diagnosing it?

I've read the following question:

But I'm not using the elsarticle or acronym packages, so the accepted answer didn't apply to me.

More info: As suggested, I did a kind of 'commenting out' binary search. (By the way, if LaTeX knows that labels may have changed, why can't it tell me which labels?)

Anyway, I seemed to track down the problem to a specific figure. When I compile only chapters 1 to 3, removing that figure also removes the warning. However, if I once again include all chapters, removing that figure isn't enough. So I guess there are other problem locations. But I don't have time to search chapters 4 to 9 right now...

I can also tell you this: I have a tmp directory where LaTeX and friends dump all temporary files. And between two compilations, the relevant content of this directory does not change at all. That is to say, diff -r tells me that the only changes are some timestamps and the .pdf file. In particular: all .aux files are identical.

Community
  • 1
mhelvens
  • 6,126
  • Did you try to delete aux file? – Sigur Jan 17 '14 at 16:48
  • An orthogonal fix : One of my favorite TeXperts Paul Isambert wrote silence with an entertaining manual. Look at yax too while you are at it which is slowly replacing pgfkeys for me. – percusse Jan 17 '14 at 16:50
  • The possible culprit might be some float that keeps changing its position due to the previous recalculation and it never stops doing so. Something like, when in 0 go to 1, when in 1 go to 0. – Paulo Cereda Jan 17 '14 at 16:52
  • 3
    Did you try the method of dividing the input into two in order to find the part that's responsible for the changing label? – egreg Jan 17 '14 at 16:54
  • 1
    The divide and "concur" can only work to a certain extent in this case. You can find by this method the shortest prefix of the code in which the problem occurs. The jumpy reference should occur at the end of this prefix. But, it could be that the jumpiness is a result of numbered reference, which, e.g., changes from three digits to four if the file is long enough. – Yossi Gil Jan 17 '14 at 17:21
  • 4
    Check if the varioref package is used. It's a common culprit for this kind of behaviour. The only fix would be to use a normal \ref at the point that's responsible or change the text slightly so the \vref isn't at a page boundary anymore. https://en.wikibooks.org/wiki/LaTeX/Labels_and_Cross-referencing#The_varioref_package – Christian Jan 17 '14 at 17:55
  • Hi all. I updated my question with new information. (1) @Sigur: While testing I routinely remove all .aux files, so that's not it. – mhelvens Jan 18 '14 at 14:32
  • (2) @percusse: That's very useful, thanks! :-) But for now I'm just worried that some reference is actually shifting around in my document. – mhelvens Jan 18 '14 at 14:33
  • 1
    (3) @PauloCereda: Take a look at my extended answer. The auxiliary files stay identical between compiles. To add to that: the figure in question does not move in the .pdf. – mhelvens Jan 18 '14 at 14:35
  • (4) @egreg: Check my extended answer. I did, and tracked (part of) it down to a specific figure. But I'm still not sure how this figure could be responsible! – mhelvens Jan 18 '14 at 14:36
  • (5) @Christian: Thanks for the suggestion. varioref is not used by me, directly or indirectly. However, I do use cleveref extensively. – mhelvens Jan 18 '14 at 14:38
  • 1
    The fact that removing the figure and reinstating the missing chapter makes the problem reappear might mean that you have two similar situations. – egreg Jan 18 '14 at 14:46
  • @egreg: Indeed. But let's pretend for the moment that my document is only three chapters long. How could the presence of this figure be responsible for the warning, given that when present it remains firmly in place, and the auxiliary files don't change at all between compilations? Perhaps if I know the answer, I won't have to repeat my binary search in chapters 4 to 9. The process takes a long time, especially for later chapters. As @ YossiGil said, I have to keep the whole prefix for every test. – mhelvens Jan 18 '14 at 14:49
  • cleveref shouldn't be an issue since it doesn't change the reference text depending on the relative position of the reference and the referenced object as varioref does (and which can therefore cause such problems). – Christian Jan 18 '14 at 17:16
  • what packages are you actually using? when testing footmisc, i was able to construct a pathological per-page footnote arrangement that caused this diagnostic. it rather sounds as if your figures aren't (really) at fault. – wasteofspace Jan 28 '14 at 17:09
  • 1
    Relevant: Understanding how references and labels work – Werner Jan 28 '14 at 17:16
  • 1
    I had a similar problem when using hyperref and a figure caption which contained an active character. The problem was that hyperref (and rerunfilecheck) compared the caption and the caption written to a file (with expansion), and that my home-brewed active character was not robust. Perhaps your figure caption contains a fragile command? – Bruno Le Floch Jan 28 '14 at 17:30
  • 1
    Run a compile a few times. Copy your .aux file. Rerun the compile again, and then compare the .aux files. – bombcar Mar 13 '14 at 14:42
  • Are your figures in floating environments or are they fixed? I would try making them all fixed environments -- try redefining the figure environment so that it does nothing. Floats shouldn't move from one compile to the next, but I've always thought that floats were a little random so I'm inclined to (unfairly) blame them. –  Mar 17 '14 at 04:20
  • @Andrew: Worth a try, thanks. :-) I had to put this problem on the back burner for a while, but it's time I did something about it. – mhelvens Mar 17 '14 at 10:53

3 Answers3

37

(By the way, if LaTeX knows that labels may have changed, why can't it tell me which labels?)

The following document will give the re-run error message each time.

\documentclass{article}

\makeatletter


% \def\@testdef #1#2#3{%
%   \def\reserved@a{#3}\expandafter \ifx \csname #1@#2\endcsname
%  \reserved@a  \else
% \typeout{^^Jlabel #2 changed:^^J%
% \meaning\reserved@a^^J%
% \expandafter\meaning\csname #1@#2\endcsname^^J}%
% \@tempswatrue \fi}


\begin{document}
\providecommand\r@foo{{1}{1}}
\edef\@currentlabel{.\expandafter\@firstoftwo\r@foo}
\label{foo}
a

\end{document}

produces a log

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

If you uncomment the block in the preamble you get an additional diagnostic telling you which label has changed, and the old and new definition:

label foo changed:
macro:->{............1}{1}
macro:->{...........1}{1}

)

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.
David Carlisle
  • 757,742
  • Awesome. :-) Will try this when I get home. – mhelvens Apr 03 '14 at 14:31
  • 1
    Thanks to this diagnostic trick, I was finally able to fix the issue. It turns out, the captions of all offending labels had inline math with a _ (subscript) inside (though the before/after versions were always identical). Replacing these was all I had to do! --- I am unable to reproduce this in a minimal document. Can't say I'm surprised. I hacked around in my thesis code so much, it's hardly LaTeX anymore. --- Thanks! – mhelvens Apr 06 '14 at 18:14
  • 1
    @DavidCarlisle This diagose does not always work. I still get an infinite loop without any hints. – user877329 Aug 31 '15 at 11:04
  • @user877329 can't really say anything to a small comment, if you can make a reproducible example, please ask a new question, posting the code. – David Carlisle Aug 31 '15 at 11:06
  • @DavidCarlisle If you know a trick that works regardless of what packages you have, regardless of situation, post it. Your trick works for the first two runs, but fails on all remaining. I use harvard varioref hyperref cleveref glossaries (in that order). – user877329 Aug 31 '15 at 11:13
  • @user877329 without an example demonstrating the problem I couldn't even start to guess:-) – David Carlisle Aug 31 '15 at 11:16
  • @user877329 a new question with a test case is probably more likely to make it easier to solve your problem than a bounty. As it is I can't guess why this answer doesn't solve the problem. – David Carlisle Aug 31 '15 at 18:40
  • For completeness, the example should also call \makeatother after the commented code. – languitar Dec 01 '17 at 11:25
  • This is a life-saver. In my case it turns out I have some character in the caption that LaTeX doesn't like ... – Weijun Zhou Apr 28 '19 at 05:01
  • Is it reasonable to leave this diagnostic code turned on all the time, for a large document (hundreds of pages)? – Norman Ramsey Aug 14 '19 at 22:40
  • 1
    @NormanRamsey I guess so, it's my code so it must be safe, I think... (I can't see any real downsides) – David Carlisle Aug 14 '19 at 22:42
1

I had this issue too. I used David's excellent little snippet to catch changed references. Since the log file is very long, I grepped them out with:

$ egrep -A2 "label .* changed:" jobname.log

In my case, I found that the unstable labels were of the form pgfidnnnn, which I believe come from using the TikZ key remember picture. And they weren't changing by much. Per the manual's suggestion, I had placed \tikzstyle{every picture}+=[remember picture] in my document's preamble. I shut off this blanket option and the unstable labels disappeared.

Matthew Leingang
  • 44,937
  • 14
  • 131
  • 195
  • In my case it was the \linegoal macro from the linegoal packet which repeatedly jumped between two calculations of the remaining line width. Using a hardcoded width instead of linegoal fixed it thanks do David's code! – Elarion Jul 25 '20 at 23:06
  • 1
    In my case it was the breqn package. – Onner Irotsab Jan 12 '22 at 10:23
1

@Onner Irotsab In my case, it was also breqn but why would this package cause this 'Label(s) changed warning' message?

Shahmeer
  • 43