C++ implementation of the Google logging module

Google Logging Library

Build Status Grunt status

The Google Logging Library (glog) implements application-level logging. The library provides logging APIs based on C++-style streams and various helper macros.

Getting Started

You can log a message by simply streaming things to LOG(<a particular severity level>), e.g.,

#include <glog/logging.h>

int main(int argc, char* argv[]) {
    // Initialize Google’s logging library.

    // ...
    LOG(INFO) << "Found " << num_cookies << " cookies";

For a detailed overview of glog features and their usage, please refer to the user guide.

Building from Source

glog supports multiple build systems for compiling the project from source: Bazel, CMake, and vcpkg.


To use glog within a project which uses the Bazel build tool, add the following lines to your WORKSPACE file:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

    name = "com_github_gflags_gflags",
    sha256 = "34af2f15cf7367513b352bdcd2493ab14ce43692d2dcd9dfc499492966c64dcf",
    strip_prefix = "gflags-2.2.2",
    urls = ["https://github.com/gflags/gflags/archive/v2.2.2.tar.gz"],

    name = "com_github_google_glog",
    sha256 = "62efeb57ff70db9ea2129a16d0f908941e355d09d6d83c9f7b18557c0a7ab59e",
    strip_prefix = "glog-d516278b1cd33cd148e8989aec488b6049a4ca0b",
    urls = ["https://github.com/google/glog/archive/d516278b1cd33cd148e8989aec488b6049a4ca0b.zip"],

You can then add @com_github_google_glog//:glog to the deps section of a cc_binary or cc_library rule, and #include <glog/logging.h> to include it in your source code. Here’s a simple example:

    name = "main",
    srcs = ["main.cc"],
    deps = ["@com_github_google_glog//:glog"],


glog also supports CMake that can be used to build the project on a wide range of platforms. If you don’t have CMake installed already, you can download it for from CMake’s official website.

CMake works by generating native makefiles or build projects that can be used in the compiler environment of your choice. You can either build glog with CMake as a standalone project or it can be incorporated into an existing CMake build for another project.

Building glog with CMake

When building glog as a standalone project, on Unix-like systems with GNU Make as build tool, the typical workflow is:

  1. Get the source code and change to it. e.g., cloning with git:
git clone [email protected]:google/glog.git
cd glog
  1. Run CMake to configure the build tree.
cmake -H. -Bbuild -G "Unix Makefiles"

Note: to get the list of available generators (e.g., Visual Studio), use -G ""

  1. Afterwards, generated files can be used to compile the project.
cmake --build build
  1. Test the build software (optional).
cmake --build build --target test
  1. Install the built files (optional).
cmake --build build --target install

Consuming glog in a CMake Project

If you have glog installed in your system, you can use the CMake command find_package to build against glog in your CMake Project as follows:

cmake_minimum_required (VERSION 3.0.2)
project (myproj VERSION 1.0)

find_package (glog 0.5.0 REQUIRED)

add_executable (myapp main.cpp)
target_link_libraries (myapp glog::glog)

Compile definitions and options will be added automatically to your target as needed.

Incorporating glog into a CMake Project

You can also use the CMake command add_subdirectory to include glog directly from a subdirectory of your project by replacing the find_package call from the previous example by add_subdirectory. The glog::glog target is in this case an ALIAS library target for the glog library target.

Again, compile definitions and options will be added automatically to your target as needed.


The url of vcpkg is: https://github.com/Microsoft/vcpkg You can download and install glog using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./vcpkg integrate install
./vcpkg install glog

The glog port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

User Guide

glog defines a series of macros that simplify many common logging tasks. You can log messages by severity level, control logging behavior from the command line, log based on conditionals, abort the program when expected conditions are not met, introduce your own verbose logging levels, and more.

Following sections describe the functionality supported by glog. Please note this description may not be complete but limited to the most useful ones. If you want to find less common features, please check header files under src/glog directory.

Severity Levels

You can specify one of the following severity levels (in increasing order of severity): INFO, WARNING, ERROR, and FATAL. Logging a FATAL message terminates the program (after the message is logged). Note that messages of a given severity are logged not only in the logfile for that severity, but also in all logfiles of lower severity. E.g., a message of severity FATAL will be logged to the logfiles of severity FATAL, ERROR, WARNING, and INFO.

The DFATAL severity logs a FATAL error in debug mode (i.e., there is no NDEBUG macro defined), but avoids halting the program in production by automatically reducing the severity to ERROR.

Unless otherwise specified, glog writes to the filename /tmp/\<program name\>.\<hostname\>.\<user name\>.log.\<severity level\>.\<date\>.\<time\>.\<pid\> (e.g., /tmp/hello_world.example.com.hamaji.log.INFO.20080709-222411.10474). By default, glog copies the log messages of severity level ERROR or FATAL to standard error (stderr) in addition to log files.

Setting Flags

Several flags influence glog’s output behavior. If the Google gflags library is installed on your machine, the configure script (see the INSTALL file in the package for detail of this script) will automatically detect and use it, allowing you to pass flags on the command line. For example, if you want to turn the flag --logtostderr on, you can start your application with the following command line:

./your_application --logtostderr=1

If the Google gflags library isn’t installed, you set flags via environment variables, prefixing the flag name with GLOG_, e.g.,

GLOG_logtostderr=1 ./your_application

The following flags are most commonly used:

logtostderr (bool, default=false)
Log messages to stderr instead of logfiles. Note: you can set binary flags to true by specifying 1, true, or yes (case insensitive). Also, you can set binary flags to false by specifying 0, false, or no (again, case insensitive).
stderrthreshold (int, default=2, which is ERROR)
Copy log messages at or above this level to stderr in addition to logfiles. The numbers of severity levels INFO, WARNING, ERROR, and FATAL are 0, 1, 2, and 3, respectively.
minloglevel (int, default=0, which is INFO)
Log messages at or above this level. Again, the numbers of severity levels INFO, WARNING, ERROR, and FATAL are 0, 1, 2, and 3, respectively.
log_dir (string, default="")
If specified, logfiles are written into this directory instead of the default logging directory.
v (int, default=0)
Show all VLOG(m) messages for m less or equal the value of this flag. Overridable by --vmodule. See the section about verbose logging for more detail.
vmodule (string, default="")
Per-module verbose level. The argument has to contain a comma-separated list of <module name>=<log level>. <module name> is a glob pattern (e.g., gfs* for all modules whose name starts with "gfs"), matched against the filename base (that is, name ignoring .cc/.h./-inl.h). <log level> overrides any value given by --v. See also the section about verbose logging.

There are some other flags defined in logging.cc. Please grep the source code for DEFINE_ to see a complete list of all flags.

You can also modify flag values in your program by modifying global variables FLAGS_* . Most settings start working immediately after you update FLAGS_* . The exceptions are the flags related to destination files. For example, you might want to set FLAGS_log_dir before calling google::InitGoogleLogging . Here is an example:

LOG(INFO) << "file";
// Most flags work immediately after updating values.
FLAGS_logtostderr = 1;
LOG(INFO) << "stderr";
FLAGS_logtostderr = 0;
// This won’t change the log destination. If you want to set this
// value, you should do this before google::InitGoogleLogging .
FLAGS_log_dir = "/some/log/directory";
LOG(INFO) << "the same file";

Conditional / Occasional Logging

Sometimes, you may only want to log a message under certain conditions. You can use the following macros to perform conditional logging:

LOG_IF(INFO, num_cookies > 10) << "Got lots of cookies";

The "Got lots of cookies" message is logged only when the variable num_cookies exceeds 10. If a line of code is executed many times, it may be useful to only log a message at certain intervals. This kind of logging is most useful for informational messages.

LOG_EVERY_N(INFO, 10) << "Got the " << google::COUNTER << "th cookie";

The above line outputs a log messages on the 1st, 11th, 21st, ... times it is executed. Note that the special google::COUNTER value is used to identify which repetition is happening.

You can combine conditional and occasional logging with the following macro.

LOG_IF_EVERY_N(INFO, (size > 1024), 10) << "Got the " << google::COUNTER
                                        << "th big cookie";

Instead of outputting a message every nth time, you can also limit the output to the first n occurrences:

LOG_FIRST_N(INFO, 20) << "Got the " << google::COUNTER << "th cookie";

Outputs log messages for the first 20 times it is executed. Again, the google::COUNTER identifier indicates which repetition is happening.

Debug Mode Support

Special "debug mode" logging macros only have an effect in debug mode and are compiled away to nothing for non-debug mode compiles. Use these macros to avoid slowing down your production application due to excessive logging.

DLOG(INFO) << "Found cookies";
DLOG_IF(INFO, num_cookies > 10) << "Got lots of cookies";
DLOG_EVERY_N(INFO, 10) << "Got the " << google::COUNTER << "th cookie";

CHECK Macros

It is a good practice to check expected conditions in your program frequently to detect errors as early as possible. The CHECK macro provides the ability to abort the application when a condition is not met, similar to the assert macro defined in the standard C library.

CHECK aborts the application if a condition is not true. Unlike assert, it is *not* controlled by NDEBUG, so the check will be executed regardless of compilation mode. Therefore, fp->Write(x) in the following example is always executed:

CHECK(fp->Write(x) == 4) << "Write failed!";

There are various helper macros for equality/inequality checks - CHECK_EQ, CHECK_NE, CHECK_LE, CHECK_LT, CHECK_GE, and CHECK_GT. They compare two values, and log a FATAL message including the two values when the result is not as expected. The values must have operator<<(ostream, ...) defined.

You may append to the error message like so:

CHECK_NE(1, 2) << ": The world must be ending!";

We are very careful to ensure that each argument is evaluated exactly once, and that anything which is legal to pass as a function argument is legal here. In particular, the arguments may be temporary expressions which will end up being destroyed at the end of the apparent statement, for example:

CHECK_EQ(string("abc")[1], ’b’);

The compiler reports an error if one of the arguments is a pointer and the other is NULL. To work around this, simply static_cast NULL to the type of the desired pointer.

CHECK_EQ(some_ptr, static_cast<SomeType*>(NULL));

Better yet, use the CHECK_NOTNULL macro:


Since this macro returns the given pointer, this is very useful in constructor initializer lists.

struct S {
    S(Something* ptr) : ptr_(CHECK_NOTNULL(ptr)) {}
    Something* ptr_;

Note that you cannot use this macro as a C++ stream due to this feature. Please use CHECK_EQ described above to log a custom message before aborting the application.

If you are comparing C strings (char *), a handy set of macros performs case sensitive as well as case insensitive comparisons - CHECK_STREQ, CHECK_STRNE, CHECK_STRCASEEQ, and CHECK_STRCASENE. The CASE versions are case-insensitive. You can safely pass NULL pointers for this macro. They treat NULL and any non-NULL string as not equal. Two NULLs are equal.

Note that both arguments may be temporary strings which are destructed at the end of the current "full expression" (e.g., CHECK_STREQ(Foo().c_str(), Bar().c_str()) where Foo and Bar return C++’s std::string).

The CHECK_DOUBLE_EQ macro checks the equality of two floating point values, accepting a small error margin. CHECK_NEAR accepts a third floating point argument, which specifies the acceptable error margin.

Verbose Logging

When you are chasing difficult bugs, thorough log messages are very useful. However, you may want to ignore too verbose messages in usual development. For such verbose logging, glog provides the VLOG macro, which allows you to define your own numeric logging levels. The --v command line option controls which verbose messages are logged:

VLOG(1) << "I’m printed when you run the program with --v=1 or higher";
VLOG(2) << "I’m printed when you run the program with --v=2 or higher";

With VLOG, the lower the verbose level, the more likely messages are to be logged. For example, if --v==1, VLOG(1) will log, but VLOG(2) will not log. This is opposite of the severity level, where INFO is 0, and ERROR is 2. --minloglevel of 1 will log WARNING and above. Though you can specify any integers for both VLOG macro and --v flag, the common values for them are small positive integers. For example, if you write VLOG(0), you should specify --v=-1 or lower to silence it. This is less useful since we may not want verbose logs by default in most cases. The VLOG macros always log at the INFO log level (when they log at all).

Verbose logging can be controlled from the command line on a per-module basis:

--vmodule=mapreduce=2,file=1,gfs*=3 --v=0


  1. Print VLOG(2) and lower messages from mapreduce.{h,cc}
  2. Print VLOG(1) and lower messages from file.{h,cc}
  3. Print VLOG(3) and lower messages from files prefixed with "gfs"
  4. Print VLOG(0) and lower messages from elsewhere

The wildcarding functionality shown by (c) supports both ’*’ (matches 0 or more characters) and ’?’ (matches any single character) wildcards. Please also check the section about command line flags.

There’s also VLOG_IS_ON(n) "verbose level" condition macro. This macro returns true when the --v is equal or greater than n. To be used as

if (VLOG_IS_ON(2)) {
    // do some logging preparation and logging
    // that can’t be accomplished with just VLOG(2) << ...;

Verbose level condition macros VLOG_IF, VLOG_EVERY_N and VLOG_IF_EVERY_N behave analogous to LOG_IF, LOG_EVERY_N, LOF_IF_EVERY, but accept a numeric verbosity level as opposed to a severity level.

VLOG_IF(1, (size > 1024))
   << "I’m printed when size is more than 1024 and when you run the "
      "program with --v=1 or more";
   << "I’m printed every 10th occurrence, and when you run the program "
      "with --v=1 or more. Present occurence is " << google::COUNTER;
VLOG_IF_EVERY_N(1, (size > 1024), 10)
   << "I’m printed on every 10th occurence of case when size is more "
      " than 1024, when you run the program with --v=1 or more. ";
      "Present occurence is " << google::COUNTER;

Failure Signal Handler

The library provides a convenient signal handler that will dump useful information when the program crashes on certain signals such as SIGSEGV. The signal handler can be installed by google::InstallFailureSignalHandler(). The following is an example of output from the signal handler.

*** Aborted at 1225095260 (unix time) try "date -d @1225095260" if you are using GNU date ***
*** SIGSEGV (@0x0) received by PID 17711 (TID 0x7f893090a6f0) from PID 0; stack trace: ***
PC: @           0x412eb1 TestWaitingLogSink::send()
    @     0x7f892fb417d0 (unknown)
    @           0x412eb1 TestWaitingLogSink::send()
    @     0x7f89304f7f06 google::LogMessage::SendToLog()
    @     0x7f89304f35af google::LogMessage::Flush()
    @     0x7f89304f3739 google::LogMessage::~LogMessage()
    @           0x408cf4 TestLogSinkWaitTillSent()
    @           0x4115de main
    @     0x7f892f7ef1c4 (unknown)
    @           0x4046f9 (unknown)

By default, the signal handler writes the failure dump to the standard error. You can customize the destination by InstallFailureWriter().

Performance of Messages

The conditional logging macros provided by glog (e.g., CHECK, LOG_IF, VLOG, ...) are carefully implemented and don’t execute the right hand side expressions when the conditions are false. So, the following check may not sacrifice the performance of your application.

CHECK(obj.ok) << obj.CreatePrettyFormattedStringButVerySlow();

User-defined Failure Function

FATAL severity level messages or unsatisfied CHECK condition terminate your program. You can change the behavior of the termination by InstallFailureFunction.

void YourFailureFunction() {
  // Reports something...

int main(int argc, char* argv[]) {

By default, glog tries to dump stacktrace and makes the program exit with status 1. The stacktrace is produced only when you run the program on an architecture for which glog supports stack tracing (as of September 2008, glog supports stack tracing for x86 and x86_64).

Raw Logging

The header file <glog/raw_logging.h> can be used for thread-safe logging, which does not allocate any memory or acquire any locks. Therefore, the macros defined in this header file can be used by low-level memory allocation and synchronization code. Please check src/glog/raw_logging.h.in for detail.

Google Style perror()

PLOG() and PLOG_IF() and PCHECK() behave exactly like their LOG* and CHECK equivalents with the addition that they append a description of the current state of errno to their output lines. E.g.

PCHECK(write(1, NULL, 2) >= 0) << "Write NULL failed";

This check fails with the following error message.

F0825 185142 test.cc:22] Check failed: write(1, NULL, 2) >= 0 Write NULL failed: Bad address [14]


SYSLOG, SYSLOG_IF, and SYSLOG_EVERY_N macros are available. These log to syslog in addition to the normal logs. Be aware that logging to syslog can drastically impact performance, especially if syslog is configured for remote logging! Make sure you understand the implications of outputting to syslog before you use these macros. In general, it’s wise to use these macros sparingly.

Strip Logging Messages

Strings used in log messages can increase the size of your binary and present a privacy concern. You can therefore instruct glog to remove all strings which fall below a certain severity level by using the GOOGLE_STRIP_LOG macro:

If your application has code like this:

#define GOOGLE_STRIP_LOG 1    // this must go before the #include!
#include <glog/logging.h>

The compiler will remove the log messages whose severities are less than the specified integer value. Since VLOG logs at the severity level INFO (numeric value 0), setting GOOGLE_STRIP_LOG to 1 or greater removes all log messages associated with VLOGs as well as INFO log statements.

Automatically Remove Old Logs

To enable the log cleaner:

google::EnableLogCleaner(3); // keep your logs for 3 days

And then glog will check if there are overdue logs whenever a flush is performed. In this example, any log file from your project whose last modified time is greater than 3 days will be unlink()ed.

This feature can be disabled at any time (if it has been enabled)


Notes for Windows Users

glog defines a severity level ERROR, which is also defined in windows.h . You can make glog not define INFO, WARNING, ERROR, and FATAL by defining GLOG_NO_ABBREVIATED_SEVERITIES before including glog/logging.h . Even with this macro, you can still use the iostream like logging facilities:

#include <windows.h>
#include <glog/logging.h>

// ...

LOG(ERROR) << "This should work";
LOG_IF(ERROR, x > y) << "This should be also OK";

However, you cannot use INFO, WARNING, ERROR, and FATAL anymore for functions defined in glog/logging.h .

#include <windows.h>
#include <glog/logging.h>

// ...

// This won’t work.
// google::FlushLogFiles(google::ERROR);

// Use this instead.

If you don’t need ERROR defined by windows.h, there are a couple of more workarounds which sometimes don’t work:

  • #define WIN32_LEAN_AND_MEAN or NOGDI before you #include windows.h.
  • #undef ERROR after you #include windows.h .

See this issue for more detail.

Installation Notes for 64-bit Linux Systems

The glibc built-in stack-unwinder on 64-bit systems has some problems with glog. (In particular, if you are using InstallFailureSignalHandler(), the signal may be raised in the middle of malloc, holding some malloc-related locks when they invoke the stack unwinder. The built-in stack unwinder may call malloc recursively, which may require the thread to acquire a lock it already holds: deadlock.)

For that reason, if you use a 64-bit system and you need InstallFailureSignalHandler(), we strongly recommend you install libunwind before trying to configure or install google glog. libunwind can be found here.

Even if you already have libunwind installed, you will probably still need to install from the snapshot to get the latest version.

Caution: if you install libunwind from the URL above, be aware that you may have trouble if you try to statically link your binary with glog: that is, if you link with gcc -static -lgcc_eh .... This is because both libunwind and libgcc implement the same C++ exception handling APIs, but they implement them differently on some platforms. This is not likely to be a problem on ia64, but may be on x86-64.

Also, if you link binaries statically, make sure that you add -Wl,--eh-frame-hdr to your linker options. This is required so that libunwind can find the information generated by the compiler required for stack unwinding.

Using -static is rare, though, so unless you know this will affect you it probably won’t.

If you cannot or do not wish to install libunwind, you can still try to use two kinds of stack-unwinder: 1. glibc built-in stack-unwinder and 2. frame pointer based stack-unwinder.

  1. As we already mentioned, glibc’s unwinder has a deadlock issue. However, if you don’t use InstallFailureSignalHandler() or you don’t worry about the rare possibilities of deadlocks, you can use this stack-unwinder. If you specify no options and libunwind isn’t detected on your system, the configure script chooses this unwinder by default.
  2. The frame pointer based stack unwinder requires that your application, the glog library, and system libraries like libc, all be compiled with a frame pointer. This is not the default for x86-64.

How to Contribute

We’d love to accept your patches and contributions to this project. There are a just a few small guidelines you need to follow.

Contributor License Agreement (CLA)

Contributions to any Google project must be accompanied by a Contributor License Agreement. This is not a copyright assignment, it simply gives Google permission to use and redistribute your contributions as part of the project.

  • If you are an individual writing original source code and you’re sure you own the intellectual property, then you’ll need to sign an individual CLA.
  • If you work for a company that wants to allow you to contribute your work, then you’ll need to sign a corporate CLA.

You generally only need to submit a CLA once, so if you’ve already submitted one (even if it was for a different project), you probably don’t need to do it again.

Once your CLA is submitted (or if you already submitted one for another Google project), make a commit adding yourself to the AUTHORS and CONTRIBUTORS files. This commit can be part of your first pull request.

Submitting a Patch

  1. It’s generally best to start by opening a new issue describing the bug or feature you’re intending to fix. Even if you think it’s relatively minor, it’s helpful to know what people are working on. Mention in the initial issue that you are planning to work on that bug or feature so that it can be assigned to you.
  2. Follow the normal process of forking the project, and setup a new branch to work in. It’s important that each group of changes be done in separate branches in order to ensure that a pull request only includes the commits related to that bug or feature.
  3. Do your best to have well-formed commit messages for each change. This provides consistency throughout the project, and ensures that commit messages are able to be formatted properly by various git tools.
  4. Finally, push the commits to your fork and submit a pull request.
Google ❤️ Open Source
  • Add CMake support for glog

    Add CMake support for glog


    would it be possible to add cmake support for Glog ? Gflags already support cmake, it would be consistent to have glog supporting it also. It seems that there have been attempts to do that in the past.

    Thanks you very much in advance

  • ./configure && make && make install fails with error: expected initializer before 'Demangle'

    ./configure && make && make install fails with error: expected initializer before 'Demangle'

    The error is below. I see the same problem referenced in https://github.com/google/glog/pull/7, though it's not clear to me from the discussion whether this issue is fixed, and the instructions still direct users to use ./configure && make && make install.

    libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I./src -I./src -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNO_FRAME_POINTER -DNDEBUG -g -O2 -MT src/libglog_la-demangle.lo -MD -MP -MF src/.deps/libglog_la-demangle.Tpo -c src/demangle.cc  -fPIC -DPIC -o src/.libs/libglog_la-demangle.o
    In file included from src/demangle.cc:38:0:
    src/demangle.h:80:27: error: expected initializer before 'Demangle'
     bool GOOGLE_GLOG_DLL_DECL Demangle(const char *mangled, char *out, int out_size);
  • autoconf build does not version the library

    autoconf build does not version the library

    ./configure; make install and cmake ..; make install produce different libraries

    The cmake version doesn't create this missing library/symlink:


    discovered in: https://github.com/Homebrew/homebrew-core/pull/14379

  • Add support for deleting old logs

    Add support for deleting old logs

    Hi, Can we add a support for deleting old logs? As of now, log just keeps accumulating until it takes entire disk space. If we set the max log size to 10MB, glog keeps generating 10MB log files never deleting. I'd like to keep only latest 4 logs (of 10MB or smaller).

    I know there are tools which can be run to do the cleanup such as logrotate. We make Windows DLL which runs on embedded machine made by another company. We don't have control on this embedded machine, so we cannot run any program to rotate the log.

    I've added RotateLogFile function which checks for number of log files and deletes old logs. RotateLogFile is run in LogFileObject::Write as it log is rolled over and new log file is created (when max_log_size is reached).

    so if we have following 4 logs,

    log_20150617-141944.8600 log_20150618-166949.8600 log_20150619-119953.8600 log_20150620-107957.8600

    And if a new one is created, the oldest one is deleted leaving 4 logs log_20150617-141944.8600 <-Deleted log_20150618-163949.8600 log_20150619-112953.8600 log_20150620-101957.8600 log_20150621-103957.8600 <-- Created

    Has this feature been considered before? Can you add this?



  • Add support for customizing the prefix format

    Add support for customizing the prefix format

    This PR proposes a way of adding support to customize the prefix format used by glog.

    With it users can declare a callback (PrefixAttacherFunction(std::ostream&, const LogMessageInfo&)) that will receive the relevant log details for the line and a stream to write a corresponding prefix.

    That callback is enabled by passing it to a new overloaded InitGoogleLogging(). (The callback cannot be changed once the instance is initialized.)

    If no callback is specified, LogMessage will follow the same path as it does now and write the current hardcoded format.

    For an example use case, see the unit tests insrc/logging_custom_prefix_unittest.cc.

  • import of module 'glog.glog.log_severity' appears within namespace 'google'

    import of module 'glog.glog.log_severity' appears within namespace 'google'

    Hello All, I am running iOS project using react-native. I have installed pods, below is my Podfile

    _source 'https://github.com/CocoaPods/Specs.git' source 'https://github.com/goinstant/pods-specs-public'

    target ‘appName’ do platform :ios, '9.0' use_modular_headers!

    pod 'GoogleSignIn'
    pod 'GoogleMaps'    
    pod 'React', :path => './node_modules/react-native', :subspecs => [
    pod 'yoga', :path => './node_modules/react-native/ReactCommon/yoga'
    post_install do |installer|
        installer.pods_project.targets.each do |target|
            phase_name = 'Headers'
            target.build_configurations.each do |config|
                config.build_settings['SWIFT_VERSION'] = '3.0'
    pod 'ReactNativeLocalization", :path => './node_modules/react-native-localization'
    pod 'BVLinearGradient', :path => './node_modules/react-native-linear-gradient'
    pod 'DoubleConversion', :podspec => './node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
    pod 'glog', :podspec => './node_modules/react-native/third-party-podspecs/glog.podspec'
    pod 'Folly', :podspec => './node_modules/react-native/third-party-podspecs/Folly.podspec'


    So when I run my project, I get the above error. Please let me know how to fix this.

  • Port stack tracing to Windows

    Port stack tracing to Windows

    This set of patches implements the stack trace, symbolizer, and demangler for Windows, and their unit tests. It utilizes the Windows debugging APIs in "Dbghelp.h".

    There is one TODO for IsFailureSignalHandlerInstalled as I'm unsure yet how to implement it for Windows. That said, in order to make stack trace reporting work "as expected" for test failures, the data dump needs to be done immediately, instead of in the signal handler (see commit message for details).

    I've integration tested this with Mesos, and so far it is working well. I've also updated the unit tests where appropriate.

  • CMake support

    CMake support

    This series of patches adds CMake support to glog and fixes several compilation issues.

    My primary goal was to be able to compile glog on Windows using Visual Studio without any hassle. The modifications have been tested using VC 8.0 through VC 14.0 CTP 6, cygwin gcc 4.9.2, Intel C++ Compiler 15.0, Apple Clang, and on Arch Linux using gcc 4.9.2 and clang 3.6 (both static and shared builds).

    CMakeLists.txt also generates config files, which allow to use glog in CMake projects easily:

    cmake_minimum_required (VERSION 2.8.11)
    project (myproject)
    find_package (glog 0.3.4)
    add_executable (myproject myproject.cpp)
    target_link_libraries (myproject glog)

    To run the unit tests, execute:

    make test

    when using the Makefiles generator.



    Use a consistent naming and avoid platform specific terms. Also remove copy and paste code.

    @drigz Is there a way to define GLOG_EXPORT=__declspec(dllimport) for Windows builds only when glog is being used (as opposed to being compiled)?

  • Bazel support for windows

    Bazel support for windows

    Using google/glog from a bazel project on windows doesn't work. bazel/glog.bzl doesn't seem to be windows compatible (but does on linux and darwing). Is there a plan to add support for it ?

    here is the error I get :

    $> bazel build --compiler=clang-cl --cxxopt=/std:c++17 @com_google_glog//:glog
    INFO: Writing tracer profile to 'C:/users/lucbe/_bazel_lucbe/ixjskkhv/command.profile.gz'
    INFO: Analyzed target @com_google_glog//:glog (0 packages loaded, 0 targets configured).
    INFO: Found 1 target...
    ERROR: C:/users/lucbe/_bazel_lucbe/ixjskkhv/external/com_google_glog/BUILD:5:1: C++ compilation of rule '@com_google_glog//:glog' failed (Exit 1)
    In file included from external/com_google_glog/src/demangle.cc:38:
    external/com_google_glog/src/utilities.h(80,11): fatal error: 'port.h' file not found
    # include "port.h"
    1 error generated.
    Target @com_google_glog//:glog failed to build
    Use --verbose_failures to see the command lines of failed build steps.
    INFO: Elapsed time: 1.512s, Critical Path: 1.05s
    INFO: 0 processes.
    FAILED: Build did NOT complete successfully
  • glog detected wrong gflags namespace.

    glog detected wrong gflags namespace.

    • Build System
      • Ubuntu 18.04
      • gcc 7.3.0
      • cmake 3.10.2
      • gflags 2.2.1
      • glog ~~0.3.5~~ 2faa186
    • I compile gflags with cmake -DBUILD_SHARED_LIBS=ON -DGFLAGS_NAMESPACE=google -DCMAKE_INSTALL_PREFIX=/opt/gflags -DCMAKE_CXX_FLAGS=-fPIC .. and sudo make -j2 && sudo make install
    • I write a gflags demo file, and it works.
    #include <iostream>
    #include <gflags/gflags.h>
    int main(int argc, char *argv[])
      google::ParseCommandLineFlags(&argc, &argv, true);
      return EXIT_SUCCESS;
    • compile it with g++ -Wall -Wextra -Werror -std=c++11 -Wl,-rpath=/opt/gflags/lib/ -o proc main.cc -L /opt/gflags/lib -lgflags, and it works fine.
    • However glog detected wrong gflags namespace when I compile it from source. I run cmake -DCMAKE_INSTALL_RPATH=/opt/gflags/lib -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=/opt/glog -DCMAKE_BUILD_TYPE=RELEASE -DWITH_GFLAGS=ON -DCMAKE_CXX_FLAGS=-fPIC .., but it show that

    -- Looking for gflags namespace -- Looking for gflags namespace - gflags

    • Then I run cmake -L .., it shows gflags_DIR is detected correctly.


    • Then i write a glog demo
    #include <iostream>
    #include <glog/logging.h>
    int main(int , char *argv[])
      LOG(INFO) << "Hello Glog!";
      return EXIT_SUCCESS;
    • compile it with g++ -Wall -Wextra -Werror -std=c++11 -Wl,-rpath=/opt/glog/lib -o proc main.cc -L /opt/glog/lib -lglog
    • ./proc --logtostderr=1 doesn't work. It doesn't print message to stderr.
    • GLOG_logtostderr=1 ./proc works fine surely.
    • Thanks.
  • TID in the files and on the stack trace not matching

    TID in the files and on the stack trace not matching

    In the stack trace, we see something like this:

    *** SIGSEGV (@0x149d) received by PID 22298 (TID 0x36087700) from PID 5277; stack trace: ***

    In the files, we see: I1107 17:38:43.965498 22378 xx.cc:nnn]

    22378 is supposed to be the thread id and so is: 0x36087700. I skimmed over the code and seems like 2 different functions are used to compute the values:

    (a) https://github.com/google/glog/blob/a34226ca94be8faae363b0599e5c4cdb7767774a/src/signalhandler.cc#L211 (b) https://github.com/google/glog/blob/f4dd77ae6b8e5f8e1323c929e81dbc40ff58fc7b/src/utilities.cc#L259

    What is the relation between the two? How do I know which TID caused the crash?

  • Provide API for logging with per-thread counters

    Provide API for logging with per-thread counters

    This is an RFC for a feature to allow counting loggers to use thread-local variables.

    I'm writing task-based routines that spawn threads to repeatedly run a function or lambda. Currently only the thread that "wins" the shared count to N gets to log which is suboptimal for this use case.

    It would be nice to be able to periodically report progress from each thread with independent counters for each task's loop.

    If this is something we'd want to add, I'll follow up with docs and tests. Thanks for looking!

  • Some g++ symbols aren't demangled (.localalias & .cold)

    Some g++ symbols aren't demangled (.localalias & .cold)

    I linked glog 0.6.0 using this NixOS recipe (with gflags dependency removed) into my c++ application. I see a stack trace with some C++ symbols properly demangled while a few remain mangled (and good enough for c++filt to decode). E.g.

        @     0x7f051d8a618a _ZN4mlir6detail17OpToOpPassAdaptor3runEPNS_4PassEPNS_9OperationENS_15AnalysisManagerEbj.localalias
        @     0x7f051d8a6599 _ZN4mlir6detail17OpToOpPassAdaptor11runPipelineERNS_13OpPassManagerEPNS_9OperationENS_15AnalysisManagerEbjPNS_16PassInstrumentorEPKNS_19PassInstrumentation18PipelineParentInfoE.localalias
        @     0x7f051d8a54ef _ZN4mlir6detail17OpToOpPassAdaptor23runOnOperationAsyncImplEb.localalias
        @     0x7f051d8a5fd4 _ZN4mlir6detail17OpToOpPassAdaptor3runEPNS_4PassEPNS_9OperationENS_15AnalysisManagerEbj.localalias
        @     0x7f051d8a6599 _ZN4mlir6detail17OpToOpPassAdaptor11runPipelineERNS_13OpPassManagerEPNS_9OperationENS_15AnalysisManagerEbjPNS_16PassInstrumentorEPKNS_19PassInstrumentation18PipelineParentInfoE.localalias
        @     0x7f051d8a7420 mlir::PassManager::run()
        @           0x525cf8 main
        @     0x7f05088e2790 __libc_start_main
        @           0x5c3e7a _start

    which after c++filt become a pleasant to read

        @     0x7f051d8a618a mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) [clone .localalias]
        @     0x7f051d8a6599 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) [clone .localalias]
        @     0x7f051d8a54ef mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool) [clone .localalias]
        @     0x7f051d8a5fd4 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) [clone .localalias]
        @     0x7f051d8a6599 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) [clone .localalias]
        @     0x7f051d8a7420 mlir::PassManager::run()
        @           0x525cf8 main
        @     0x7f05088e2790 __libc_start_main
        @           0x5c3e7a _start

    I activate the stack trace with google::InstallFailureSignalHandler(); no further flags or configuration.

    Is there some kind of limit on the length of mangled identifiers or some other option I'm missing?

  • Link failed when WITH_THREADS is set to OFF

    Link failed when WITH_THREADS is set to OFF

    Version: v0.6.0 (should be reproducible on master) Platform: macOS 12.6 Compiler: AppleClang 14.0.0

    When WITH_THREADS options is set to OFF, linking glog will pop an linking error which says undef: __ZN6google24glog_internal_namespace_31IsFailureSignalHandlerInstalledEv

    It looks like the symbol google::glog_internal_namespace_::IsFailureSignalHandlerInstalled() is defined in src/signalhandler.cc , https://github.com/google/glog/blob/05fbc65278db1aa545ca5cb743c31bc717a48d0f/src/signalhandler.cc#L367-L381

    and the source file will not be included in the build target if WITH_THREADS is set to OFF. https://github.com/google/glog/blob/05fbc65278db1aa545ca5cb743c31bc717a48d0f/CMakeLists.txt#L530-L536 https://github.com/google/glog/blob/05fbc65278db1aa545ca5cb743c31bc717a48d0f/CMakeLists.txt#L621-L623

    Is this an intended behavior? If not, I can help to fix this.

  • Custom sink example?

    Custom sink example?

    I am considering to use glog instead a lot of custom code, but I cannot se from the docs how to achieve the following:

    • user shall select to either log to console or file (not both)
    • file should have encoded each line as a JSON, to be then be piped to a logging service.

    I see from the code that glog support custom sinks, but I cannot find an example.

Related tags
Reckless logging. Low-latency, high-throughput, asynchronous logging library for C++.
Reckless logging. Low-latency, high-throughput, asynchronous logging library for C++.

Introduction Reckless is an extremely low-latency, high-throughput logging library. It was created because I needed to perform extensive diagnostic lo

Dec 1, 2022
Colorful Logging is a simple and efficient library allowing for logging and benchmarking.
Colorful Logging is a simple and efficient library allowing for  logging and benchmarking.

Colorful-Logging "Colorful Logging" is a library allowing for simple and efficient logging as well for benchmarking. What can you use it for? -Obvious

Feb 17, 2022
Yet another logging library.

Blackhole - eating your logs with pleasure Blackhole is an attribute-based logger with strong focus on gaining maximum performance as possible for suc

Dec 2, 2022
log4cplus is a simple to use C++ logging API providing thread-safe, flexible, and arbitrarily granular control over log management and configuration. It is modelled after the Java log4j API.

% log4cplus README Short Description log4cplus is a simple to use C++17 logging API providing thread--safe, flexible, and arbitrarily granular control

Nov 27, 2022
A lightweight C++ logging library
A lightweight C++ logging library

Loguru: a lightweight and flexible C++ logging library. At a glance Documentation Documentation can be found at https://emilk.github.io/loguru/index.h

Nov 23, 2022
Portable, simple and extensible C++ logging library
Portable, simple and extensible C++ logging library

Plog - portable, simple and extensible C++ logging library Pretty powerful logging library in about 1000 lines of code Introduction Hello log! Feature

Nov 26, 2022
Fast C++ logging library.

spdlog Very fast, header-only/compiled, C++ logging library. Install Header only version Copy the source folder to your build tree and use a C++11 com

Dec 1, 2022
Asynchronous Low Latency C++ Logging Library

Quill Asynchronous Low Latency C++ Logging Library Introduction Features Performance Supported Platforms And Compilers Basic Usage CMake Integration D

Nov 30, 2022
Cute Log is a C++ Library that competes to be a unique logging tool.

Cute Log Cute Log is a C++ Library that competes to be a unique logging tool. Version: 2 Installation Click "Code" on the main repo page (This one.).

Oct 13, 2022
fmtlog is a performant fmtlib-style logging library with latency in nanoseconds.

fmtlog fmtlog is a performant asynchronous logging library using fmt library format. Features Faster - lower runtime latency than NanoLog and higher t

Nov 30, 2022
Minimalistic logging library with threads and manual callstacks

Minimalistic logging library with threads and manual callstacks

Jun 24, 2022
A Fast and Convenient C++ Logging Library for Low-latency or Real-time Environments

xtr What is it? XTR is a C++ logging library aimed at applications with low-latency or real-time requirements. The cost of log statements is minimised

Jul 17, 2022
Uberlog - Cross platform multi-process C++ logging system

uberlog uberlog is a cross platform C++ logging system that is: Small Fast Robust Runs on Linux, Windows, OSX MIT License Small Two headers, and three

Sep 29, 2022
logog is a portable C++ library to facilitate logging of real-time events in performance-oriented applications

logog is a portable C++ library to facilitate logging of real-time events in performance-oriented applications, such as games. It is especially appropriate for projects that have constrained memory and constrained CPU requirements.

Oct 21, 2020
Boost Logging library

Boost.Log, part of collection of the Boost C++ Libraries, provides tools for adding logging to libraries and applications. Directories build - Boost.L

Nov 20, 2022
📝 Kernel module that can be used as a replacement for logger or logwrapper

Kernel logger Kernel logger is a kernel module that can be used as a replacement for logger or logwrapper. Its log is similar to systemd's journal and

May 21, 2022
A single file, public domain C implementation of aSchroeder reverb.

Introduction This is a reverb implementation based on Freeverb, a public domain reverb written by Jezar at Dreampoint in 2000. The library is written

Nov 27, 2022