cxref

What it does

cxref scans a set of C source files and produces a cross-reference listing: for each function and global variable, where it's defined and every location (file and line number) where it's referenced elsewhere in the program. It was used to help developers navigate and understand large C codebases before interactive tooling existed to do the same thing on demand. It is a niche, largely legacy tool today — it is not packaged on current mainstream Linux distributions or macOS, and its purpose has been thoroughly superseded by interactive tools: ctags/gtags for building a fast symbol index, and language servers like clangd (used via editors such as VS Code or Neovim) for real-time "go to definition" and "find all references."

Beginner examples

• cxref -xref file.c — historical usage: generate a cross-reference listing for a single file
• cxref -xref *.c — cross-reference an entire directory of C source files
• Because cxref is largely unavailable today, the realistic starting point is its modern replacements:
• ctags -R . — build a tags index across a whole project for editor navigation
• grep -rn "function_name(" . — a quick, always-available way to find references manually

ctags -R .

Advanced examples

• Historical workflow: run cxref across a whole project's source tree and review the generated report to understand call relationships before making a change.
• Modern equivalent for the same investigative goal, using a language server in an editor: open the project in VS Code or Neovim with clangd configured, and use "Find All References" / "Go to Definition" directly, incrementally, and without a separate build step.
• Modern equivalent for a lightweight, scriptable cross-reference: combine ctags with grep to answer "where is this symbol defined and used" without a full IDE: ctags -R . && grep -rn "\bmy_func\b" --include=*.c .

grep -rn "\bmy_variable\b" --include="*.c" --include="*.h" .

Common mistakes

• Trying to install cxref on a modern system and finding it isn't packaged, or is only available from very old archives — treat this as a signal to use ctags/clangd instead.
• Expecting cxref-style static reports to stay accurate as code changes — any static cross-reference listing goes stale the moment the source changes, which is exactly why interactive, on-demand tools like language servers have displaced this approach.
• Confusing cross-referencing (mapping where symbols are defined/used) with compiling — cxref (like ctags) doesn't build or check the program, it only indexes symbol usage.

Tips

• If cxref is referenced in old build tooling or documentation, treat it as historical context and replace the workflow with ctags/gtags plus your editor's navigation features, or a clangd-based setup for richer semantic queries.
• ctags -R . takes seconds on most codebases and gives you jump-to-definition in vi, Emacs, and most modern editors without any of cxref's setup overhead.
• For deep semantic queries (call hierarchies, type-aware "find references"), a language server like clangd is far more accurate than any static-listing tool, since it actually parses the code with full type information.

Best practices

• Use ctags/gtags or a language-server-backed editor for symbol navigation on current projects instead of reaching for cxref.
• Regenerate symbol indexes (ctags) as part of your normal workflow (e.g. a git hook) so navigation data doesn't go stale, addressing the core weakness that legacy static cross-referencers like cxref had.
• Don't introduce new dependencies on cxref in active tooling; its function is better served by actively maintained alternatives.

Real-world use cases

• Historical/archival context: understanding how developers navigated large C codebases before IDEs and language servers existed.
• Modernizing legacy documentation tooling that referenced cxref by switching to ctags/gtags or clangd-based navigation.
• Teaching context: explaining the lineage from static cross-reference tools (cxref) to today's language-server-based "find references" features.

Common interview questions

• What did cxref do, conceptually? It statically scanned C source files and produced a report showing where each function and global variable was defined and every place it was referenced, similar in spirit to a "find all references" report but generated offline as a static listing.
• Why is cxref considered obsolete? Because interactive tools — ctags/gtags for fast symbol indexing, and language servers like clangd for semantically accurate, real-time navigation — provide the same information more conveniently, more accurately (with full type awareness), and without going stale between regenerations.
• What would you use today instead of cxref? ctags or gtags for a lightweight, editor-integrated symbol index, or a language-server-protocol tool like clangd for richer, type-aware "go to definition" and "find references" functionality.