Your Step-by-Step Fix

Let's get your build working again. Follow these steps in order; don't skip the easy ones first!

Step 1: Ensure a Clean Build

This is non-negotiable. Toolchain upgrades leave stale artifacts. Delete your entire build directory and re-run your configuration and build process from scratch.

$ rm -rf build/
$ cmake -B build -DCMAKE_C_COMPILER=clang-22 -DCMAKE_CXX_COMPILER=clang++-22 ...
$ cmake --build build

For many, this simple step alone resolves the linker errors.

Step 2: Update Compiler and Linker Flags

Clang-22 has clarified the best way to handle sanitizer linking. Review your build flags and update them according to the new recommendations. A key change is the deprecation of manual linking flags like -static-libasan in favor of a unified compiler-driver approach.

Ensure these flags are applied to both your compile and link steps. The easiest way is to set them in your CMAKE_CXX_FLAGS or equivalent.

Step 3: Addressing Global Initializer Issues

If you're still facing runtime crashes after a clean build with the right flags, it's time to look at your code. The culprit is almost certainly a complex static global constructor.

Problematic Pattern (Before):

// Some helper function that might allocate memory or have side effects
std::string get_default_user() {
  // ... maybe reads a config file, allocates memory ...
  return "default_user";
}

// Global map that calls a function during initialization
std::map<std::string, std::string> g_config = {
  {"user", get_default_user()}
}; 

int main() {
  // By the time we get here, ASan has already crashed during
  // the initialization of g_config.
  return 0;
}

This pattern is fragile. The initialization of g_config happens before main(), in an environment where ASan is trying to get set up. The call to get_default_user() could do anything, and Clang-22's ASan no longer permits this ambiguity.

The Solution: The 'Construct on First Use' Idiom

The best fix is to delay the initialization until the object is actually needed. This is a well-known pattern, sometimes called a Meyers' Singleton. The object is declared as a function-local static, so it's only constructed the first time the function is called—long after main() has started and ASan is safely initialized.

Corrected Pattern (After):

// The helper function is fine
std::string get_default_user() {
  return "default_user";
}

// A function that provides access to the config map
std::map<std::string, std::string>& get_config() {
  // The map is now a function-local static variable. It will be initialized
  // only the first time get_config() is called. This is thread-safe in C++11+.
  static std::map<std::string, std::string> config = {
    {"user", get_default_user()}
  };
  return config;
}

int main() {
  // ASan initializes successfully, no global constructors to worry about.
  
  // Now, when we first need the config, we call the function.
  // The map is constructed here, safely.
  std::string user = get_config()["user"];
  
  return 0;
}

This pattern is not only safer for sanitizers but is also generally better software design, as it improves startup time and clarifies dependencies.

Future-Proofing Your Sanitizer Builds

To avoid being caught off guard by the next toolchain update, consider integrating these practices into your workflow:

• Minimize Global State: The less work you do before main(), the fewer problems you'll have. The 'Construct on First Use' idiom is your friend.
• Run CI Against Compiler Nightlies: Set up a non-blocking CI job that builds and tests your project against the trunk/main branches of Clang and GCC. This gives you weeks or months of advance warning about breaking changes.
• Pin Toolchain Versions: For your production and release builds, explicitly pin the compiler version. This prevents surprises and ensures reproducibility. Upgrade deliberately, not accidentally.
• Read the Release Notes: The LLVM/Clang release notes are detailed and almost always contain a section on non-obvious changes or newly deprecated features. Make reading them part of your upgrade process.

Conclusion

Encountering a breaking change in a tool as critical as AddressSanitizer can be frustrating, but it's often a sign of progress. The changes in Clang-22, while disruptive, push us toward writing more robust, predictable, and correct code by shining a light on risky patterns like complex global initializers.

By following the steps of cleaning your build, updating your flags, and refactoring problematic globals, you can resolve the incompatibility and benefit from the improved bug-finding capabilities of the new sanitizer. These aren't just patches; they're improvements that will make your codebase healthier and more resilient for the long term. Happy debugging!