# How can I ensure varioref generates unique labels when the document is split into separate files?

After adding the varioref package (to generate text like "Figure XX on page YY" from TeX input like \vref{fig:example}), I started seeing warnings like

LaTeX Warning: Label 1@xvr' multiply defined.
LaTeX Warning: Label 1@vr' multiply defined.


My document has chapters stored in separate files: chapter1.tex, chapter2.tex, etc., which are referenced from the master document using

\include{Chapter1/chapter1}
\include{Chapter2/chapter2}
...


I traced the problem to the fact that varioref generates its own xvr and vr labels by concatenating a counter with @xvr and with @vr. It seems that this counter is reset for each file. For example, in my document, chapter5.aux contains

\newlabel{1@xvr}{{}{181}{Review of ...}{subsection.5.3.2}{}}
\newlabel{1@vr}{{}{181}{Review of ...}{subsection.5.3.2}{}}


and chapter6.aux contains

\newlabel{1@xvr}{{}{198}{Introduction to ...}{section.6.1}{}}
\newlabel{1@vr}{{}{198}{Introduction to ...}{section.6.1}{}}


Clearly, the labels generated by varioref are duplicates across chapters, though they are unique within a chapter. I wish to fix the problem because I do not have confidence that, when referencing a label in a different chapter (say, \vref{sec:Introduction to ...} from chapter5.tex in the example above), the page reference will be correct in all cases.

Update: It seems that that varioref does not always work well with forked versions of CUED thesis template. YMMV!

• Labels must be unique across the document; varioref has nothing to do with the problem. – egreg May 18 '16 at 13:35
• Thank you @egreg The issue is that varioref generates its own labels according to the algorithm above. These auto-generated labels are the only labels that LaTeX claims are not unique in the document. I was hoping there might be some way to influence how varioref generates its labels. – rugplots May 18 '16 at 13:48
• What are the related main \label commands? – egreg May 18 '16 at 13:55
• In chapter5.tex the example is \label{subsec:Review of ...} which LaTeX converts to \newlabel{subsec:Review of ...}{{5.3.2}{181}{Review of ...}{subsection.5.3.2}{}} in chapter5.aux. Compare with the first block of \newlabel statements generated by varioref in the question above. – rugplots May 18 '16 at 14:02
• Sorry, but I cannot reproduce the problem. – egreg May 18 '16 at 14:07

varioref uses a saved version of the \label command to generate such labels in the .aux file:

\def\vref@label#1{\@bsphack
\protected@write\@auxout{}%
{\string\newlabel{#1}{{}{\thepage}}}%
\@esphack}


This is more or less identical to the definition of \label in latex.ltx except that it doesn't pass \@currentlabel to \newlabel.

The real reason for having this saved version is that babel and amsmath redefine \label in a way unsuitable for varioref's purpose here.

However, the mods done in these template seem to result in the LaTeX counter vrcnt being reset per include (or perhaps generally per chapter?) and so you get double labels.

In varioref it is defined simply by

\newcounter{vrcnt}


so it should not be reset ever. Perhaps the mod changes \newcounter?

So my suggestions would be

1. to try loading varioref as early as possible perhaps even with \RequirePackage before the class or if that doesn't work

2. explicitly set it yourself per chapter file, e.g.,

\setcounter{vrcnt}{1000}


incrementing by 1000 for each chapter - it is a manual workaround but I guess it would work.

3. or you might try changing \vref@label to include \thechapter in the label name or what ever is needed to make the labels unique again, e.g.

\makeatletter
\def\vref@label#1{\@bsphack
\protected@write\@auxout{}%
{\string\newlabel{\thechapter:#1}{{}{\thepage}}}%
\@esphack}
\makeatother


in the preamble.

Ultimately the people having done the class file would need to look there as this is a bit weird that the counter is reset for no good reason.

• Thanks very much @FrankMittelbach. I followed suggestion 1 and it solved my problem. I had added the varioref package late in the list of such packages and moved it to the front of the list as you suggested. If I later run into difficulties, I can always fall back on suggestions 2 and 3; I believe they should work too! – rugplots May 19 '16 at 10:46