If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/google/glog shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 12mo ago
• 14 active contributors
• BSD-3-Clause licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 12mo ago
• ⚠ Concentrated ownership — top contributor handles 74% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live google/glog repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/google/glog.

What it runs against: a local clone of google/glog — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in google/glog | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 387 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of google/glog. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/google/glog.git
#   cd glog
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of google/glog and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "google/glog(\\.git)?\\b" \\
  && ok "origin remote is google/glog" \\
  || miss "origin remote is not google/glog (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/glog/logging.h" \\
  && ok "src/glog/logging.h" \\
  || miss "missing critical file: src/glog/logging.h"
test -f "src/logging.cc" \\
  && ok "src/logging.cc" \\
  || miss "missing critical file: src/logging.cc"
test -f "src/glog/flags.h" \\
  && ok "src/glog/flags.h" \\
  || miss "missing critical file: src/glog/flags.h"
test -f "src/flags.cc" \\
  && ok "src/flags.cc" \\
  || miss "missing critical file: src/flags.cc"
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 387 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~357d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/google/glog"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Google Logging (glog) is a C++14 library providing application-level logging with stream-based APIs (LOG, VLOG, CHECK macros) and severity-based filtering. It writes logs to files with built-in log rotation, symbol stripping for production binaries, and custom sink support—solving the problem of production-grade structured logging in C++ without external dependencies. Monorepo structure: src/glog/ contains core logging implementation (glog/logging.h, glog/raw_logging.h, glog/vlog_is_on.h), src/base/ has platform-specific utilities, bazel/ and cmake/ dirs provide dual build system support, examples/ and docs/ contain sample usage and architecture docs. Core macros LOG(), VLOG(), CHECK() expand into severity-routed logging calls that ultimately write to file via FileObject classes.

C++ backend engineers and systems developers building high-performance services (Google-scale infrastructure, databases, distributed systems) who need efficient, low-overhead logging with automatic file rotation, severity filtering, and minimal runtime overhead in production deployments.

DEPRECATED AND ABANDONED: The project is no longer maintained and will be archived 2025-06-30 (per README.rst). While battle-tested in production at Google for years, active development has stopped. There are 6 active GitHub workflows (linux, macos, windows, android, emscripten, cifuzz) and comprehensive tests, but no recent commits visible in the data—the library is in maintenance-only mode.

HIGH RISK FOR NEW PROJECTS: The official notice recommends migrating to ng-log (API-compatible community fork) or Abseil Logging (Google-maintained). Glog has zero planned updates post-archive date; any bugs found will not be fixed upstream. Dependency on gflags (for flags parsing) adds a hard external requirement. Single-maintainer abandonment is the primary risk.

No active development—the project is in archival status. CI workflows (GitHub Actions in .github/workflows/) run on every commit to validate builds across Linux, macOS, Windows, Android, and Emscripten, but no new features are being added. The last meaningful work was maintenance of build systems (CMake, Bazel) and test infrastructure.

Clone and build with CMake (preferred for new projects, or use Bazel for Google-style builds): git clone https://github.com/google/glog.git && cd glog && mkdir build && cd build && cmake .. && make. Dependencies: gflags library (cmake/DetermineGflagsNamespace.cmake detects it), optional libunwind (cmake/FindUnwind.cmake) for better stack traces.

Daily commands: After build: run examples with ./bazel/example/main.cc (Bazel) or compiled binary from cmake build dir. Logs write to /tmp/glog-test.* by default (Linux) or TEMP dir (Windows). Control via GLOG_* environment variables (GLOG_logtostderr=1 sends logs to stderr, GLOG_v=2 enables verbose level 2).

• src/glog/logging.h — Core public API header defining LOG(), VLOG(), DCHECK() macros and logging infrastructure that all contributors must understand.
• src/logging.cc — Main logging implementation containing the Logger class and log message processing logic—essential for understanding how logs flow through the system.
• src/glog/flags.h — Public interface for glog configuration flags (log levels, output directories, etc.) that control runtime behavior.
• src/flags.cc — Flag initialization and handling implementation that integrates with gflags for runtime configuration.
• CMakeLists.txt — Primary build configuration file; contributors must understand the build system and dependencies to compile and test changes.
• src/stacktrace.h — Stack unwinding and backtrace capture interface used for crash handling and debugging support across platforms.
• src/demangle.cc — Symbol demangling implementation critical for producing readable stack traces and function names in log output.

Add a new log severity level

1. Define the new severity constant in src/glog/log_severity.h using the LogSeverity enum (src/glog/log_severity.h)
2. Update src/logging.h to add a corresponding LOG_XXX() macro for the new severity (src/glog/logging.h)
3. Add handling logic in src/logging.cc's LogMessage::Flush() to route messages with the new severity (src/logging.cc)
4. Add test cases in src/logging_unittest.cc to verify the new severity level works (src/logging_unittest.cc)

Add a new configuration flag

1. Declare the flag in src/glog/flags.h as an external variable with appropriate type (src/glog/flags.h)
2. Initialize and define the flag in src/flags.cc using DEFINE_* gflags macros (src/flags.cc)
3. Read the flag in src/logging.cc's relevant functions to apply the configuration (src/logging.cc)
4. Add test coverage in src/logging_unittest.cc to verify the flag's behavior (src/logging_unittest.cc)

Add platform-specific stack unwinding support

1. Add platform detection macro in src/glog/platform.h if needed (src/glog/platform.h)
2. Implement unwinding in src/stacktrace.cc with platform-conditional compilation blocks (src/stacktrace.cc)
3. Reference the new implementation in existing stacktrace function dispatcher (src/stacktrace.h)
4. Update CMakeLists.txt to link against platform-specific unwind libraries (FindUnwind.cmake) (CMakeLists.txt)

Create a custom log sink

1. Study the example at examples/custom_sink.cc to understand the sink interface (examples/custom_sink.cc)
2. Subclass or implement the sink interface as defined in src/glog/logging.h (LogSink) (src/glog/logging.h)
3. Register the sink by calling google::AddLogSink() in your application initialization code (src/logging.cc)

• C++14 — Provides template metaprogramming for compile-time log level filtering, stream-based API for intuitive logging syntax, and cross-platform compatibility.
• gflags (command-line flags) — Enables runtime configuration of log levels, output directories, and buffering without recompilation.
• libunwind / DWARF unwinding — Provides portable stack trace capture across Linux, macOS, and Windows for crash dumps and DCHECK failures.
• CMake + Bazel dual build systems — CMake for traditional C++ projects; Bazel for large monorepos and incremental builds.

• Synchronous file I/O in LogMessage::Flush()

  • Why: Ensures all log data is persisted before returning from LOG() calls, preventing loss on crash.
  • Consequence: Adds 1-5ms latency per log statement; can be bottleneck in high-throughput scenarios; users must use buffering flags or custom async sinks for performance.

• Stack unwinding in signal handlers (signalhandler.cc)

  • Why: Captures backtraces at the exact point of crash for debugging fatal errors.
  • Consequence: Requires async-signal-safe code; limits demangling and formatting capabilities; raw_logging.cc provides minimal-dependency alternative.

• Compile-time log level filtering via NDEBUG and DCHECK macros

  • Why: Eliminates overhead of disabled log statements in release builds.
  • Consequence: VLOG() and DCHECK() statements are removed entirely when NDEBUG is defined; cannot enable them at runtime without recompilation.

• Global static logger state (g_log_destination, g_log_sink_list)

  • Why: Single point of control for all logging in a process; simplifies thread synchronization.
  • Consequence: Not composable for embedded systems; thread safety via mutex; complicates testing and library initialization order.

• Asynchronous logging (user must implement custom sink for buffered/async output)
• Structured logging in JSON (only text-based line-oriented logs)
• Real-time log streaming network transport (logs written to local filesystem only)
• Windows Event Log integration (uses file I/O on Windows, not native event tracing)
• Automatic log rotation and compression (log_cleaner separate utility; not built-in)
• Multi-process/multi-machine log aggregation

1. gflags required: glog depends on gflags for flag parsing (GLOG_v, GLOG_logtostderr, etc.); cmake/DetermineGflagsNamespace.cmake auto-detects namespace but will fail if gflags is absent. 2) Log file paths platform-specific: logs write to /tmp on Unix, TEMP dir on Windows; hardcoded in src/logging.cc, not easily configurable at runtime. 3) Signal safety: RAW_LOG in src/base/logging.h must be used in signal handlers; normal LOG() is not async-signal-safe. 4) Symbol stripping caveat: docs/log_stripping.md notes that glog's symbol stripping requires binaries compiled with specific flags (read that doc before production deployments). 5) Deprecated status: no bugfixes will be accepted; migration off glog is recommended (README explicitly points to ng-log and Abseil as replacements).

• Log Rotation and File Naming Scheme — glog automatically creates numbered log files (e.g., program.log.INFO.20231125-120000.1234) and cleans old ones; understanding src/logging.cc's FileObject::CreateLogMessage() logic is essential for customizing rotation behavior or debugging disk usage in production.
• Severity-Based Filtering and Symbol Stripping — glog uses compile-time and runtime severity levels (INFO, WARNING, ERROR, FATAL) to filter logs and optionally strips debug symbols for production; docs/log_stripping.md explains how to use glog's binary rewriting tools to reduce binary size while preserving readable stack traces.
• Async-Signal-Safe Logging (RAW_LOG) — glog provides RAW_LOG macro (src/base/logging.h) that is safe to call from signal handlers; understanding why LOG() is not signal-safe (uses locks, memory allocation) is critical for handlers that must log crashes or faults.
• Pluggable LogSink Interface — glog's LogSink base class (src/glog/logging.h) allows users to redirect, filter, or aggregate logs to custom destinations (Syslog, cloud logging, in-memory buffers); examples/custom_sink.cc shows the exact interface to implement.
• Conditional Compilation and Verbose Logging (VLOG) — glog's VLOG(level) macro enables verbose logging controlled by GLOG_v flag; understanding how glog/vlog_is_on.h compiles away VLOG statements at high verbosity levels avoids runtime overhead in production.
• Cross-Platform Abstraction for Logging — glog's src/base/ directory contains Windows vs Unix-specific implementations (src/windows/port.cc, src/unix/port.cc) for file handles, thread IDs, and temp directories; understanding these abstractions is needed to extend glog or debug platform-specific issues.
• Stack Unwinding and Symbol Resolution — glog optionally uses libunwind (detected in cmake/FindUnwind.cmake) to capture and print call stacks in FATAL logs; understanding how glog resolves symbols and formats stack traces helps interpret production crashes.

• abseil/abseil-cpp — Abseil Logging is Google's maintained replacement for glog with modern C++17+ API and better performance; recommended migration path in glog README
• ng-log/ng-log — Community-maintained fork of glog with identical API, active development, and drop-in replacement; primary alternative for projects unable to migrate to Abseil
• gflags/gflags — Hard dependency of glog for command-line flag parsing (GLOG_v, GLOG_logtostderr); cmake/DetermineGflagsNamespace.cmake auto-detects and links it
• google/googletest — Test framework used throughout glog (src/*_test.cc files); CI workflows run tests against multiple platforms
• bazelbuild/bazel — Primary build system preferred by glog maintainers; BUILD.bazel files and .bazelci/presubmit.yml show Bazel is the reference build

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for src/demangle.cc with cross-platform coverage

The src/demangle_unittest.sh exists but is a shell script with a static .txt file (src/demangle_unittest.txt). There's also src/demangle_unittest.cc but no corresponding CMake/Bazel integration visible. Given the project supports multiple platforms (Android, Emscripten, Windows, macOS, Linux), the demangle functionality needs robust cross-platform testing. This would improve reliability of symbol demangling across all supported architectures.

• [ ] Review src/demangle.cc and src/demangle_unittest.cc to understand current test coverage
• [ ] Expand src/demangle_unittest.cc with additional edge cases (malformed symbols, compiler-specific mangling, platform-specific patterns)
• [ ] Ensure CMakeLists.txt and BUILD.bazel both properly register the demangle_unittest target
• [ ] Run tests across all CI platforms (Linux, macOS, Windows, Android, Emscripten) via existing workflows
• [ ] Document any platform-specific behaviors in docs/logging.md

Implement log_cleaner functionality tests for src/cleanup_*_unittest.cc files

Three cleanup test files exist (src/cleanup_immediately_unittest.cc, src/cleanup_with_absolute_prefix_unittest.cc, src/cleanup_with_relative_prefix_unittest.cc) but docs/log_cleaner.md describes log cleaning features without corresponding integration tests. The file structure suggests incomplete test coverage for the log rotation and cleanup mechanisms, which are critical for production reliability.

• [ ] Review docs/log_cleaner.md to understand all log cleanup scenarios and edge cases
• [ ] Audit the three cleanup_*_unittest.cc files for completeness (test file rotation, prefix handling, permission issues)
• [ ] Add missing test cases for: disk full scenarios, concurrent cleanup, symlink handling, and permission denials
• [ ] Integrate tests into CMakeLists.txt and BUILD.bazel with proper test data directories
• [ ] Add platform-specific tests for Windows log cleanup (src/cleanup_*_unittest.cc currently may lack Windows coverage)

Add GitHub Actions workflow for Bazel build and test validation (missing from .github/workflows/)

The repo has BUILD.bazel, MODULE.bazel, and .bazelci/presubmit.yml configuration but no dedicated GitHub Actions workflow for Bazel validation. Currently, CI workflows (.github/workflows/linux.yml, windows.yml, etc.) likely only test CMake builds. This creates a testing gap for Bazel users and the Bazel build system itself.

• [ ] Create .github/workflows/bazel.yml workflow file
• [ ] Add jobs for: Bazel build (Linux), Bazel build (macOS), Bazel build (Windows), Bazel test suite
• [ ] Reference existing .bazelci/presubmit.yml configuration where applicable
• [ ] Test across multiple Bazel versions (last 3 major versions minimum)
• [ ] Validate bazel/example/BUILD.bazel and bazel/example/main.cc execute successfully
• [ ] Ensure workflow runs on pull requests and main branch commits

• Add integration tests for Windows custom sink (examples/custom_sink.cc exists but .github/workflows/windows.yml does not include a sink test target; create src/windows_custom_sink_test.cc and update CMakeLists.txt to verify cross-platform sink API consistency).
• Document the undocumented GLOG_* environment variables in docs/flags.md (GLOG_minloglevel, GLOG_buffer_logs, GLOG_logbufsecs are used in src/logging.cc but not listed in public docs; extract them with grep and write descriptions).
• Add CMake cross-compile example for Android (CMAKE_SYSTEM_NAME=Android is not shown in docs/build.md, but .github/workflows/android.yml builds it; create docs/android_cross_compile.md with exact CMake invocation).

The glog project presents significant security concerns primarily due to its deprecated and end-of-life status, with no planned security maintenance after 2025-06-30. The C++14 codebase may contain memory safety vulnerabilities typical of native code logging libraries. While the dependency versions are pinned, they will not receive updates. Immediate action is required for any production deployments: migrate to ng-log or Abseil Logging before the archive date. The project is not recommended for new development or long-term usage.

• Critical · Project Deprecation and End of Life — README.rst, project root. The Google Logging Library (glog) project is officially deprecated and will be archived on 2025-06-30. The project is no longer maintained, meaning no security patches, bug fixes, or updates will be provided after that date. This poses a significant security risk for any production systems depending on this library. Fix: Migrate to actively maintained alternatives: ng-log (API-compatible community-maintained fork) or Abseil Logging (Google-maintained). Plan and execute migration before the archive date.
• Medium · Potential Outdated Dependencies in Documentation Pipeline — docs/requirements.txt. The project uses several mkdocs-related dependencies for documentation generation. While specific versions are pinned in requirements.txt, the mkdocs-git-committers-plugin-2 and mkdocs-git-revision-date-localized-plugin packages may have known vulnerabilities. Given the project is deprecated, these dependencies will not receive security updates. Fix: Audit all dependencies in docs/requirements.txt for known CVEs using tools like safety or pip-audit. If vulnerabilities exist, they cannot be remediated in the official project; consider this when using in production.
• Medium · Deprecated C++ Standard and Potential Memory Safety Issues — src/ directory, entire codebase. The project is a C++14 library that implements low-level logging functionality. C++14 lacks modern memory safety features. The codebase likely contains manual memory management that could be vulnerable to use-after-free, buffer overflows, or double-free vulnerabilities common in C++ logging libraries. Fix: Conduct a comprehensive code review focusing on memory management patterns. Consider using modern C++ (C++17+) features, smart pointers, and bounds checking. Alternatively, migrate to memory-safe alternatives like Rust-based logging libraries.
• Low · CI/CD Configuration Exposure — .github/workflows/ directory. The repository contains CI/CD workflow files (.github/workflows/) that define build and test processes. While this is standard practice, ensure these workflows do not expose secrets, API keys, or sensitive credentials in logs or artifacts. Fix: Review all workflow files to ensure secrets are properly managed using GitHub Secrets. Verify that no credentials are logged during build/test execution. Enable secret scanning in the repository settings.
• Low · Missing Security Policy Documentation — Repository root. No visible SECURITY.md or security policy file is present in the repository. Given the deprecation status, there should be clear guidance on security issue reporting and the lack of patches. Fix: Create a SECURITY.md file clarifying that the project is deprecated, will not receive security updates, and direct users to report issues to maintained alternatives rather than this project.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.