I'm having issues getting cleveref to recognize references when using revtex4-2. When compiling, all references give a warning "LaTeX Warning: cref reference format for label type `' undefined on input line ..." and fail to typeset correctly. I've seen cref reference format for label type `' undefined, as well as a number of issues regarding cleveref and appendix sections on this site, but my issue is seems unrelated because switching to revtex4-1 fixes the problem in my case. Here's a MWE




\section{First section}


\section{Second section}

Hello \cref{sec:first}


As expected, I have to run pdflatex twice to get the references right, but once I do everything renders correctly. However, if I replace the documentclass with revtex4-2, then the contents of the "Second section" read "Hello ??". I'm running on Mac OS and I've updated all my packages using Tex Live Utility, so I don't think it's a versioning issue, but rather something in how revtex4-2 is redefining some internal TeX macros. Unfortunately I don't know enough to dig into the details there.

EDIT One extra piece of information that may be useful to future viewers of this issue: adding the hyperref option to the list of documentclass options does not resolve this issue. However, avoiding that option and instead explicitly writing \usepackage{hyperref} (before \usepackage{cleveref}) does resolve the problem.


1 Answer 1


Not a full solution, but hopefully a satisfactory work-around: Load hyperref before cleveref. (If you don't want colored hyperlinks, load hyperref with the options colorlinks and allcolors=black.)

I browsed the contents of revtex4-2.cls. It looks like somebody made an effort to change the default properties of LaTeX's \label macro, possibly to make life easier for hyperref, which does its own furthering doctoring of \label. By loading hyperref, this further doctoring is accomplished, thereby making way for cleveref to do its own, additional doctoring of \label.

In sum, what appears to be going on is that the revtex4-2 document class has changed the properties of \label in a such way that cleveref can no longer apply its own further patches successfully; hence the ?? output. By loading hyperref as well, the properties of \label get changed further, but happily in a such way that cleveref once more knows what to do. (Aside: If hyperref and cleveref are both loaded, it is well known that cleveref must be loaded after hyperref. It was this piece of knowledge that led me to investigate whether loading hyperref might provide a work-around for the problem at hand...)

enter image description here


\section{First section}\label{sec:first}

\section{Second section} \label{sec:second}
Hello \cref{sec:first}.

Hello \crefrange{sec:first}{sec:second}.
  • 2
    Great call! I specifically removed hyperref because I knew about the interaction and wanted to create a minimal example, and it didn't occur to me that hyperref could actually fix the problem. Would you consider this a bug that I should report to the maintainers of revtex, or is this likely to be the expected behavior going forward?
    – Vyas
    Mar 12, 2020 at 15:19
  • @Vyas - Thanks. I'm not in a position to judge whether the revtex42 modifications amount to a bug. (FWIW, if I were in charge of their LaTeX coding, I'd definitely apply the mods to the \label macro only if the hyperref`` package were loaded.) If you want to contact them and draw their attention to the fact that their modifications to the \label` macro make the basic revtex42 document class code incompatible with the cleveref package, I would assume that they'd very much appreciate learning about this issue.
    – Mico
    Mar 12, 2020 at 17:14
  • 2
    I sent them an email letting them know about this issue.
    – Vyas
    Mar 12, 2020 at 17:26
  • I've tried the above solution with loading hyperref but it's not solving the problem: ``` text \Cref{a} ... \section{s_a} \label{a} ``` shows Section without a number. Using: Debian testing pdfTeX 3.141592653-2.6-1.40.22 cleveref 2018-03-27 revtex 4.2a Any suggestions?. Thanks
    – jzz11
    Jul 8, 2022 at 15:46
  • @jzz11 - Thanks for alerting me to this issue. It would appear that the workaround I suggested in the answer shown above, which I posted more than 2 years ago, no longer works an with up-to-date version of the LaTeX format file. Not sure why. All I can surmise is that the extended hook management methods LaTeX started providing in the fall of 2020 have something to do with this mess. For sure, I can't get the test document shown above to compile correctly inmy MacTeX2022 distribution (pdfTeX Version 3.141592653-2.6-1.40.24, LaTeX2e <2022-06-01> patch level 5). Truly sorry I can't say more.
    – Mico
    Jul 8, 2022 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .