Methods for debugging package conflicts

Question

... 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}
Your command was ignored.
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.

Answer 1

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.