# Methods for debugging package conflicts

... that don't make me want to pull my (remaining) hair out.

I'm preparing a long journal article with a wide array of necessary packages and a publisher-specific class file.

In this specific case, I've recently added

\usepackage{algorithm}
\usepackage[noend]{algpseudocode}


When building the TeX file I'm now encountering a typical conflict error:

 ("C:\Program Files\MiKTeX 2.9\tex\latex\algorithms\algorithm.sty"
Package: algorithm 2009/08/24 v0.1 Document Style algorithm' - floating environment

! LaTeX Error: Command \c@algorithm already defined.
Or name \end... illegal, see p.192 of the manual.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
...

l.96 \floatname
{algorithm}{\ALG@name}
Type  I <command> <return>  to replace it with another command,
or  <return>  to continue without it.


The resulting PDF looks fine, including the new algorithms, but since I'm collaborating on the source with other parties—and since I'm the kind of person who has nightmares about unbalanced parentheses—I don't want to commit changes that introduce error messages.

Aside from this specific case (which I assume is quite specialised, but which serves as a useful example), I'm wondering if there's any methods or helpful tips to debug conflicts like this? I have tried commenting out various packages to do a "binary search" on the problematic package, but then I encounter other errors or the build fails due to the necessary packages being omitted. I have tried building up the packages from an MWE but it is time consuming given the complexity of the document and not (yet) yielding any insights.

This leads me to wonder if there's a better way ... how would a TeX expert approach the problem?

For example, are there any hints to be had from the pdfTex .log file as to where \c@algorithm is already defined? Is there another method to trace where the definition is? Maybe the definition can be renamed before including the algorithm package? Maybe there's an online resource that offers a matrix of typical package conflicts? Or maybe there's some other general method to identify and resolve such conflicts?

(Of course, there's a bunch of incompatibility questions already on this site, but I could not find any that address generic methods on how to identify conflicts/incompatibilities.)

EDIT: Thanks to the comments below and David's help, I was able to fix the specific case, which relates to both the elsart class file I'm using and the algorithm package I've included defining a counter for algorithms. The method to identify this conflict was to go through the log file as David suggested to find where the \c@algorithm counter was registered. To resolve the problem, I added \makeatletter\let\c@algorithm\relax\makeatother before including the algorithm package.

The question remains open as to generic methods (such as looking through the nested file inclusions in the log file) for identifying and resolving conflicts.

• Cheers David, I had tried that. If I comment out the import of algorithm in the article, it indeed removes the error, but I lose the horizontal-lined framing of the algorithms. But weirdly, if I set up an MWE to test this, I can keep both the algorithm and algpseudocode packages without a problem. Hence it seems there's somehow a "third party" involved. – badroit Aug 14 '13 at 16:05
• \c@algorithm  is the latex counter algorithm so you have declared the counter twice. although I get no clash if I load those two, and your error is on loading algorithm, ie before algpseudocode is loaded so you must have another algorithm??? package loaded? – David Carlisle Aug 14 '13 at 16:08
• The log should show a line when the c@algorithm register is allocated and looking up to the preceding ( will tell you which file that is in – David Carlisle Aug 14 '13 at 16:09
• no latexsym doesn't declare that, I suspect that the ) marking the close of latexsym.sty is before that line, you need to match () pairs as they mark file open/close – David Carlisle Aug 14 '13 at 16:18
• you can probably just \makeatletter\let\c@algorithm\relax\makeatother before loading your algorithm package, then it'll get re-allocated which wastes one register but... – David Carlisle Aug 14 '13 at 17:15

You can locate where the register \c@algorithm is being defined by looking in the log file for a line
\c@algorithm=\count??

Then working out which package file was being read at that time by working backwards up the log file matching ( and ) which mark the open and close of files by TeX's file reading system. The full path to each opened file is shown after the ( and a )` is printed to the log when the end of file has been reached.