The gflags package contains a C++ library that implements commandline flags processing.

Related tags

CLI gflags
Overview

Build Status Build status

The documentation of the gflags library is available online at https://gflags.github.io/gflags/.

11 November 2018

I've just released gflags 2.2.2.

This maintenance release improves life of Bazel users (no more "config.h" leaking into global include paths), fixes build with recent MinGW versions, and silences a number of static code analyzer and compiler warnings. The build targets exported by the CMake configuration of this library are now also prefixed by the package name "gflags::" following a more recent (unwritten) CMake convention. The unprefixed target names are still supported to avoid that dependent projects have to be modified due to this change in imported target names.

Please report any further issues with this release using the GitHub issue tracker.

11 July 2017

I've just released gflags 2.2.1.

This maintenance release primarily fixes build issues on Windows and false alarms reported by static code analyzers.

Please report any further issues with this release using the GitHub issue tracker.

25 November 2016

I've finally released gflags 2.2.0.

This release adds support for use of the gflags library as external dependency not only in projects using CMake, but also Bazel, or pkg-config. One new minor feature is added in this release: when a command flag argument contains dashes, these are implicitly converted to underscores. This is to allow those used to separate words of the flag name by dashes to do so, while the flag variable names are required to use underscores.

Memory leaks reported by valgrind should be resolved by this release. This release fixes build errors with MS Visual Studio 2015.

Please report any further issues with this release using the GitHub issue tracker.

24 March 2015

I've just released gflags 2.1.2.

This release completes the namespace change fixes. In particular, it restores binary ABI compatibility with release version 2.0. The deprecated "google" namespace is by default still kept as primary namespace while symbols are imported into the new "gflags" namespace. This can be overridden using the CMake variable GFLAGS_NAMESPACE.

Other fixes of the build configuration are related to the (patched) CMake modules FindThreads.cmake and CheckTypeSize.cmake. These have been removed and instead the C language is enabled again even though gflags is written in C++ only.

This release also marks the complete move of the gflags project from Google Code to GitHub. Email addresses of original issue reporters got lost in the process. Given the age of most issue reports, this should be negligable.

Please report any further issues using the GitHub issue tracker.

30 March 2014

I've just released gflags 2.1.1.

This release fixes a few bugs in the configuration of gflags_declare.h and adds a separate GFLAGS_INCLUDE_DIR CMake variable to the build configuration. Setting GFLAGS_NAMESPACE to "google" no longer changes also the include path of the public header files. This allows the use of the library with other Google projects such as glog which still use the deprecated "google" namespace for the gflags library, but include it as "gflags/gflags.h".

20 March 2014

I've just released gflags 2.1.

The major changes are the use of CMake for the build configuration instead of the autotools and packaging support through CPack. The default namespace of all C++ symbols is now "gflags" instead of "google". This can be configured via the GFLAGS_NAMESPACE variable.

This release compiles with all major compilers without warnings and passed the unit tests on Ubuntu 12.04, Windows 7 (Visual Studio 2008 and 2010, Cygwin, MinGW), and Mac OS X (Xcode 5.1).

The SVN repository on Google Code is now frozen and replaced by a Git repository such that it can be used as Git submodule by projects. The main hosting of this project remains at Google Code. Thanks to the distributed character of Git, I can push (and pull) changes from both GitHub and Google Code in order to keep the two public repositories in sync. When fixing an issue for a pull request through either of these hosting platforms, please reference the issue number as described here. For the further development, I am following the Git branching model with feature branch names prefixed by "feature/" and bugfix branch names prefixed by "bugfix/", respectively.

Binary and source packages are available on GitHub.

14 January 2014

The migration of the build system to CMake is almost complete. What remains to be done is rewriting the tests in Python such they can be executed on non-Unix platforms and splitting them up into separate CTest tests. Though merging these changes into the master branch yet remains to be done, it is recommended to already start using the cmake-migration branch.

20 April 2013

More than a year has past since I (Andreas) took over the maintenance for gflags. Only few minor changes have been made since then, much to my regret. To get more involved and stimulate participation in the further development of the library, I moved the project source code today to GitHub. I believe that the strengths of Git will allow for better community collaboration as well as ease the integration of changes made by others. I encourage everyone who would like to contribute to send me pull requests. Git's lightweight feature branches will also provide the right tool for more radical changes which should only be merged back into the master branch after these are complete and implement the desired behavior.

The SVN repository remains accessible at Google Code and I will keep the master branch of the Git repository hosted at GitHub and the trunk of the Subversion repository synchronized. Initially, I was going to simply switch the Google Code project to Git, but in this case the SVN repository would be frozen and force everyone who would like the latest development changes to use Git as well. Therefore I decided to host the public Git repository at GitHub instead.

Please continue to report any issues with gflags on Google Code. The GitHub project will only be used to host the Git repository.

One major change of the project structure I have in mind for the next weeks is the migration from autotools to CMake. Check out the (unstable!) cmake-migration branch on GitHub for details.

25 January 2012

I've just released gflags 2.0.

The google-gflags project has been renamed to gflags. I (csilvers) am stepping down as maintainer, to be replaced by Andreas Schuh. Welcome to the team, Andreas! I've seen the energy you have around gflags and the ideas you have for the project going forward, and look forward to having you on the team.

I bumped the major version number up to 2 to reflect the new community ownership of the project. All the changes are related to the renaming. There are no functional changes from gflags 1.7. In particular, I've kept the code in the namespace google, though in a future version it should be renamed to gflags. I've also kept the /usr/local/include/google/ subdirectory as synonym of /usr/local/include/gflags/, though the former name has been obsolete for some time now.

18 January 2011

The google-gflags Google Code page has been renamed to gflags, in preparation for the project being renamed to gflags. In the coming weeks, I'll be stepping down as maintainer for the gflags project, and as part of that Google is relinquishing ownership of the project; it will now be entirely community run. The name change reflects that shift.

20 December 2011

I've just released gflags 1.7. This is a minor release; the major change is that CommandLineFlagInfo now exports the address in memory where the flag is located. There has also been a bugfix involving very long --help strings, and some other minor changes.

29 July 2011

I've just released gflags 1.6. The major new feature in this release is support for setting version info, so that --version does something useful.

One minor change has required bumping the library number: ReparseCommandlineFlags now returns void instead of int (the int return value was always meaningless). Though I doubt anyone ever used this (meaningless) return value, technically it's a change to the ABI that requires a version bump. A bit sad.

There's also a procedural change with this release: I've changed the internal tools used to integrate Google-supplied patches for gflags into the opensource release. These new tools should result in more frequent updates with better change descriptions. They will also result in future ChangeLog entries being much more verbose (for better or for worse).

See the ChangeLog for a full list of changes for this release.

24 January 2011

I've just released gflags 1.5. This release has only minor changes from 1.4, including some slightly better reporting in --help, and an new memory-cleanup function that can help when running gflags-using libraries under valgrind. The major change is to fix up the macros (DEFINE_bool and the like) to work more reliably inside namespaces.

If you have not had a problem with these macros, and don't need any of the other changes described, there is no need to upgrade. See the ChangeLog for a full list of changes for this release.

11 October 2010

I've just released gflags 1.4. This release has only minor changes from 1.3, including some documentation tweaks and some work to make the library smaller. If 1.3 is working well for you, there's no particular reason to upgrade.

4 January 2010

I've just released gflags 1.3. gflags now compiles under MSVC, and all tests pass. I really never thought non-unix-y Windows folks would want gflags, but at least some of them do.

The major news, though, is that I've separated out the python package into its own library, python-gflags. If you're interested in the Python version of gflags, that's the place to get it now.

10 September 2009

I've just released gflags 1.2. The major change from gflags 1.1 is it now compiles under MinGW (as well as cygwin), and all tests pass. I never thought Windows folks would want unix-style command-line flags, since they're so different from the Windows style, but I guess I was wrong!

The other changes are minor, such as support for --htmlxml in the python version of gflags.

15 April 2009

I've just released gflags 1.1. It has only minor changes fdrom gflags 1.0 (see the ChangeLog for details). The major change is that I moved to a new system for creating .deb and .rpm files. This allows me to create x86_64 deb and rpm files.

In the process of moving to this new system, I noticed an inconsistency: the tar.gz and .rpm files created libraries named libgflags.so, but the deb file created libgoogle-gflags.so. I have fixed the deb file to create libraries like the others. I'm no expert in debian packaging, but I believe this has caused the package name to change as well. Please let me know (at [mailto:[email protected] [email protected]]) if this causes problems for you -- especially if you know of a fix! I would be happy to change the deb packages to add symlinks from the old library name to the new (libgoogle-gflags.so -> libgflags.so), but that is beyond my knowledge of how to make .debs.

If you've tried to install a .rpm or .deb and it doesn't work for you, let me know. I'm excited to finally have 64-bit package files, but there may still be some wrinkles in the new system to iron out.

1 October 2008

gflags 1.0rc2 was out for a few weeks without any issues, so gflags 1.0 is now released. This is much like gflags 0.9. The major change is that the .h files have been moved from /usr/include/google to /usr/include/gflags. While I have backwards-compatibility forwarding headeds in place, please rewrite existing code to say

   #include 
   

   

instead of

   #include 
   

   

I've kept the default namespace to google. You can still change with with the appropriate flag to the configure script (./configure --help to see the flags). If you have feedback as to whether the default namespace should change to gflags, which would be a non-backwards-compatible change, send mail to [email protected]!

Version 1.0 also has some neat new features, like support for bash commandline-completion of help flags. See the ChangeLog for more details.

If I don't hear any bad news for a few weeks, I'll release 1.0-final.

Comments
  • valgrind reports 'potential memory leaks' from gflags

    valgrind reports 'potential memory leaks' from gflags

    Original issue 40 created by schuhschuh on 2010-12-13T21:23:29.000Z:

    What steps will reproduce the problem?

    1. compile a program using gflags
    2. run it with 'valgrind --leak_check=full'
    3. look at all the memory leak reports from gflags

    What is the expected output? What do you see instead?

    expected: clean memory leak report instead: saw lots of potential memory leaks

    These are not really memory leaks, but the presence of these leaks makes it harder to see real memory leaks. Note that 'potential' memory leaks are sometimes quite dangerous. For example, when working with Apache HTTPD, a large amount of memory allocation is using a pooled allocator. You can leak memory into pools, and valgrind will report that as a 'potential leak'.

    The gflags leak reports are not really problems like Apache pools, but the presence of them can obscure real problems.

    What version of the product are you using? On what operating system?

    http://google-gflags.googlecode.com/svn/tags/gflags-1.3/src (head) OS: Linux Ubtuntu 10.04.

    Please provide any additional information below.

    bug 
    opened by schuhschuh 22
  • undefined reference to 'FlagRegisterer::FlagRegisterer'

    undefined reference to 'FlagRegisterer::FlagRegisterer'

    I installed gflags first, and then failed to install glog. src/logging_unittest-logging_unittest.o: In function '__static_initialization_and_destruction_0': /opt/packages/glog-0.3.4/src/googletest.h:93: undefined reference to '::FlagRegisterer::FlagRegisterer<std::string>(char const*, char const*, char const*, std::string*, std::string*)' /opt/packages/glog-0.3.4/src/googletest.h:94: undefined reference to 'google::FlagRegisterer::FlagRegisterer<std::string>(char const*, char const*, char const*, std::string*, std::string*)' /opt/packages/glog-0.3.4/src/googletest.h:96: undefined reference to 'google::FlagRegisterer::FlagRegisterer<bool>(char const*, char const*, char const*, bool*, bool*)' /opt/packages/glog-0.3.4/src/googletest.h:100: undefined reference to 'google::FlagRegisterer::FlagRegisterer<int>(char const*, char const*, char const*, int*, int*)' collect2: error: ld returned 1 exit status make: *** [logging_unittest] Error 1

    So, I removed all libs of gflags and reinstall the glog, it worked at that time. But, when I installed folly, it prompted a similar error. How to fix it? Who can help me?

    make all-recursive make[1]: Entering directory '/opt/packages/folly/folly' Making all in . make[2]: Entering directory '/opt/packages/folly/folly' /bin/bash ./libtool --tag=CXX --mode=link g++ -std=gnu++0x -g -O2 -lboost_context -lboost_thread -lboost_filesystem -lboost_system -lboost_regex -lpthread -L/usr/local/include/double-conversion/ -o generate_fingerprint_tables build/GenerateFingerprintTables.o libfollybase.la -llzma -lz -lsnappy -llz4 -liberty -ljemalloc -levent -ldouble-conversion -lssl -lgflags -lglog libtool: link: g++ -std=gnu++0x -g -O2 -o generate_fingerprint_tables build/GenerateFingerprintTables.o -L/usr/local/include/double-conversion/ ./.libs/libfollybase.a -lboost_context -lboost_thread -lboost_filesystem -lboost_system -lboost_regex -lpthread -llzma -lz -lsnappy -llz4 -liberty -ljemalloc -levent -ldouble-conversion -lssl -lgflags -lglog /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libglog.so: undefined reference to 'google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*, char const*, void*, void*)' collect2: error: ld returned 1 exit status make[2]: *** [generate_fingerprint_tables] Error 1 make[2]: Leaving directory '/opt/packages/folly/folly' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/opt/packages/folly/folly' make: *** [all] Error 2

    question 
    opened by dearhoper 17
  • x64 platform for Google Flags on Windows

    x64 platform for Google Flags on Windows

    Original issue 36 created by schuhschuh on 2010-07-09T03:57:41.000Z:

    What steps will reproduce the problem?

    1. Download gflags 1.3
    2. Open the provided solution file
    3. Cannot build a 64-bit version

    What is the expected output? What do you see instead? There should be a 64-bit (x64) platform option for building Google Flags on Windows. Currently, only Win32 option is available

    What version of the product are you using? On what operating system? gflags 1.3 Windows 7 64-bit Visual Studio 2010

    Please provide any additional information below.

    enhancement 
    opened by schuhschuh 17
  • gflags_define <var> takes precedence over GFLAGS_<var>

    gflags_define takes precedence over GFLAGS_

    Context

    • Using gflags as subproject i.e. GFLAGS_IS_SUBPROJECT is TRUE
    • Want to build and install only the shared lib with headers
    • super project (pseudo) /CMakeLists.txt:
    cmake_minimum_required (VERSION 3.5)
    project(meta VERSION 1.0.0 LANGUAGES NONE)
    
    # well in reality I define all of this in `external` directory and 
    # I add_subdirectory() it from <root>/CMakeLists.txt
    # here I simplify the layout putting everything here
    set(BUILD_SHARED_LIBS OFF) 
    
    set(GFLAGS_NAMESPACE "gflags")
    set(GFLAGS_INSTALL_HEADERS ON)
    set(GFLAGS_BUILD_SHARED_LIBS ON)
    set(GFLAGS_INSTALL_SHARED_LIBS ON)
    set(GFLAGS_BUILD_STATIC_LIBS OFF)
    set(GFLAGS_INSTALL_STATIC_LIBS OFF)
    add_subdirectory(gflags)
    
    # contains executable foo with target_link_libraries(foo gflags::gflags)
    add_subdirectory(foo) 
    

    Observed

    • no install are generated
    • gflags_nothreads_static is built.
    • alias gflags::gflags point on it

    Expected

    • install rules for headers and shared libs (i.e. gflags_nothread is in install(TARGETS ...))
    • gflags::gflags point to gflags_nothread

    Hypothese

    IMHO the problem is, properties doesn't check GFLAGS_XXXX define see https://github.com/gflags/gflags/blob/524b83d0264cb9f1b2d134c564ef1aa23f207a41/CMakeLists.txt#L179-L182 and then you use unprefixed variables https://github.com/gflags/gflags/blob/524b83d0264cb9f1b2d134c564ef1aa23f207a41/CMakeLists.txt#L199-L201 and https://github.com/gflags/gflags/blob/524b83d0264cb9f1b2d134c564ef1aa23f207a41/CMakeLists.txt#L442

    We should use if (GFLAGS_BUILD_${TYPE}_LIBS) instead.

    Side Topics (half related)

    subproject default value seems to be out of sync (i.e. last column for INSTALL_XXX should match BUILD_XXX) IMHO see https://github.com/gflags/gflags/blob/524b83d0264cb9f1b2d134c564ef1aa23f207a41/CMakeLists.txt#L167-L168 and https://github.com/gflags/gflags/blob/524b83d0264cb9f1b2d134c564ef1aa23f207a41/CMakeLists.txt#L174-L175

    here: you build by default in STATIC only but want to install shared libs only...

    Proposal

    What's about

    gflags_define (BOOL BUILD_SHARED_LIBS
      "Request build of shared libraries."
      OFF OFF)
    gflags_define (BOOL BUILD_STATIC_LIBS
      "Request build of static libraries (default if BUILD_SHARED_LIBS is OFF)."
      OFF ON)
    gflags_define (BOOL INSTALL_SHARED_LIBS
      "Request installation of shared libraries."
      ${GFLAGS_BUILD_SHARED_LIBS}  ${GFLAGS_BUILD_SHARED_LIBS})
    gflags_define (BOOL INSTALL_STATIC_LIBS
      "Request installation of static libraries."
      ${GFLAGS_BUILD_INSTALL_LIBS}  ${GFLAGS_BUILD_INSTALL_LIBS})
    
    cmake 
    opened by Mizux 15
  • Missing gflags-targets.cmake, package registry entry, misc

    Missing gflags-targets.cmake, package registry entry, misc

    (Disclaimer: I'm only a CMake journeyman so this could be a CMake issue. Please correct me if I'm wrong.)

    TL;DR

    gflags-config.cmake seems to export gflags_INCLUDE_DIR and gflags_LIBRARIES, but not something like gflags_LIBRARY_DIR. As a result, using the default instructions, linking fails with error LNK1181: cannot open input file 'gflags.lib'.

    When built statically, the CMake config also fails to inform the generated project that it depends on Shlwapi.lib and linking fails with: "unresolved external symbol __imp_PathMatchSpecA ..."

    By manually adding the library search path to the Visual Studio project and adding Shlwapi.lib as a dependency, my project builds fine.

    Details

    I cloned and built gflags on Windows and successfully built it with VS2013:

    • cd c:\tmp\gflags-2.1.2
    • mkdir build
    • cd build
    • cmake-gui ..
    • <open .sln and build with VS2013>

    Building the INSTALL target on Windows puts everything under C:\Program Files\libraries\gflags, which has as children:

    • CMake
    • Include
    • Lib

    In my own project, I followed the directions as on https://gflags.github.io/gflags/, except to find gflags.h, I had to add include_directories( ${gflags_INCLUDE_DIR} ) to tell the compiler where to find the header. gflags_INCLUDE_DIR resolves to C:\Program Files\libraries\gflags\Include and gflags_LIBRARIES resolves to gflags.lib. However, the compiler can't find gflags.lib because there isn't a gflags_LIBRARY_DIR or something to that effect which resolves to C:\Program Files\libraries\gflags\Lib.

    cmake 
    opened by jiawen 15
  • There's no way to change what -version flag prints

    There's no way to change what -version flag prints

    Original issue 43 created by schuhschuh on 2011-02-26T09:44:37.000Z:

    What steps will reproduce the problem?

    1. Run any binary compiled with gflags with the -version argument
    2. The output will just be the program name
    3. There's no way to actually set a version

    What is the expected output? What do you see instead?

    The expectation is that gflags would support a way to add a build version that can be printed with the -version argument. Currently there's no way of doing this.

    What version of the product are you using? On what operating system?

    gflags 1.2. Ubuntu 10.10.

    Please provide any additional information below.

    The suggested way to support passing a version to gflags might be to support a DEFINE_VERSION macro that one can use to pass in the build version. The actual version might be passed to a .cc file while compiling using the g++ compiler's -D flag.

    bug 
    opened by schuhschuh 14
  • Select subset of flags on startup / conditionally allow flags

    Select subset of flags on startup / conditionally allow flags

    Original issue 46 created by schuhschuh on 2011-07-19T15:11:17.000Z:

    Sometimes it is useful to have one executable that can run in different modes, e.g., “git COMMAND [ARGS],” where the set of possible flags depend on COMMAND. Similarly, different set of flags are needed when having multiple symlinks to a single executable, whose behavior depends on argv[0].

    I have found gflags flexible enough to implement this with a few simple macros: For example, DEFINE_CONDITIONAL_int32 corresponds to DEFINE_int32, without calling the google∷FlagRegisterer. A flag is only available when registered via REGISTER_CONDITIONAL_int32() in the beginning of main(). If the flag is not registered, it would remain at its default value.

    DEFINE_CONDITIONAL_int32(lines, 20, &quot;maximal number of lines to print&quot;);
    int main(int argc; char **argv) {
        if (argc &gt;= 2 &amp;&amp; !strcmp(argv[1], &quot;print&quot;)) {
            REGISTER_CONDITIONAL_int32(lines);
       }
       google∷ParseCommandLineFlags(…);
       ...
    }
    

    It would be great if gflags would support selecting a subset of flags on startup, too. Interestingly, a somewhat similar feature, changing the default flag value on startup, is already part of gflags.

    enhancement 
    opened by schuhschuh 13
  • Move GENDIR from includes back to copts

    Move GENDIR from includes back to copts

    Hi, Bazel build fails both on v2.2.0 and on master stating that it can't find src/config.h file.

    It seems like this commit accidentally undid this fix. Putting GENDIR into includes doesn't seem to work, even when I tried doing that straight from the fix commit.

    Moving GENDIR include from includes to copts fixed the issue for me.


    This change is Reviewable

    opened by Zip753 12
  • RegisterFlagValidator warning and Simpler API

    RegisterFlagValidator warning and Simpler API

    Original issue 64 created by schuhschuh on 2013-01-14T10:33:33.000Z:

    What steps will reproduce the problem?

    1. Compile the example code in the document about RegisterFlagValidator static bool ValidatePort(const char* flagname, int32 value) { if (value > 0 && value < 32768) // value is ok return true; printf("Invalid value for --%s: %d\n", flagname, (int)value); return false; } DEFINE_int32(port, 0, "What port to listen on"); static const bool port_dummy = RegisterFlagValidator(&FLAGS_port, &ValidatePort);

    What is the expected output? What do you see instead? test.cpp:83:19: error: 'port_dummy' defined but not used

    What version of the product are you using? On what operating system? gflags 2.0, linix, gcc 4.5.1

    Please provide any additional information below.

    I think gflags can provide simpler API, such as: GFLAGS_register_validator(port, &ValidatePort);

    A candidate implementation:

    define GFLAGS_register_validator(name, validator) \

    static const bool name##validator_registered =
    ::google::RegisterFlagValidator(&FLAGS
    ##name, validator) attribute((unused))

    bug 
    opened by schuhschuh 12
  • Add pkg-config support

    Add pkg-config support

    Original issue 39 created by schuhschuh on 2010-09-23T03:11:38.000Z:

    Please consider adding pkg-config support for gflags. glog contains all the working autotools magic that you'd need to copy.

    enhancement 
    opened by schuhschuh 12
  • Run build via cmake and run tests.

    Run build via cmake and run tests.

    Hi!

    With this I was able to build and run tests (except strip_flags_binary one) for both configurations. For example, https://ci.appveyor.com/project/dreamer-dead/gflags/build/1.0.36

    With -VV ctest generate a lot of logs and it stuns AppVeyor, will look on failed test later. Locally it passes on my Windows machine. #159


    This change is Reviewable

    opened by dreamer-dead 11
  • Replace underscore

    Replace underscore "_" with dash "-" in help

    Right now gflags can be provided with options both like this "--opt_name" or "--op-name" in the console. With the help command the options are documented in the form "--op_name" (using underscore). It is more natural to document and enforce using the options using dash "-" instead of underscore "_" because it is more consistent with other tools, for example:

    ctest --help
    ....
      --build-and-test             = Configure, build and run a test.
      --build-target               = Specify a specific target to build.
      --build-nocmake              = Run the build without running cmake first.
      --build-run-dir              = Specify directory to run programs from.
      --build-two-config           = Run CMake twice
    ....
    
    opened by mciprian13 0
  • bazel build does not mark includes as system headers

    bazel build does not mark includes as system headers

    By not using includes in the cc_library for the bazel build, includes are considered local. This poses a problem for tools like clang-tidy that can suppress issues coming from system headers. As a result, our lint output is littered with gflags errors.

    opened by joshuarubin 0
  • Compilation Error: gflags.cc' is being linked both statically and dynamically into this executable

    Compilation Error: gflags.cc' is being linked both statically and dynamically into this executable

    I use gflags 2.2.0 which is compiled from source code as follows.

    mkdir bld && cd bld && CXXFLAGS="-fPIC" cmake .. -DBUILD_SHARED_LIBS=OFF && make install
    

    I set BUILD_SHARED_LIBS=OFF to make sure only static lib will be installed. When I use gflags into my project, I compile my code successfully but get error ERROR: something wrong with flag 'flagfile' in file '/xxxxx/gflags/src/gflags.cc'. One possibility: file '/xxxxx/gflags/src/gflags.cc' is being linked both statically and dynamically into this executable. on running.

    @Biswa96 @schuhschuh any idea?

    opened by GOGOYAO 1
  • Undefined symbols for architecture x86_64

    Undefined symbols for architecture x86_64

    MAC OS, I first use this tool but encountered a problem.

    1. brew install gflags
    2. test.cpp 1 #include 2 #include <gflags/gflags.h> 3 4 using namespace std; 5 6 DEFINE_int64(deu, 64, "test"); 7 int main() { 8 cout << FLAGS_deu << endl; 9 return 0; 11 }
    3. g++ test.cpp -o test

    the error log:

    Undefined symbols for architecture x86_64: "google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*, long long*, long long*)", referenced from: ___cxx_global_var_init in gflags_prac-571fbd.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

    Thank you!

    opened by HymEric 0
  • Setting Flags on the Command Line

    Setting Flags on the Command Line

    gflags supports a single-dash variant on all command line options, but it states in the text:

    Despite this flexibility, we recommend using only a single form: --variable=value for non-boolean flags, and --variable/--novariable for boolean flags.

    https://gflags.github.io/gflags/#commandline

    However, when I run --help on an application using gflags, it recommends the single-dash variant:

    [[email protected] ~]# kudu hms fix --help
    Usage:
     /bin/../lib/kudu/bin/kudu
     hms fix <master_addresses> [-dryrun] [-drop_orphan_hms_tables]
     [-nocreate_missing_hms_tables] [-nofix_inconsistent_tables]
     [-noupgrade_hms_tables] [-hive_metastore_sasl_enabled]
     [-hive_metastore_uris=<uris>] [-noignore_other_clusters]
     [-negotiation_timeout_ms=<ms>] [-timeout_ms=<ms>]
    

    Please change the output of --help to be in-line with the two-dash recomendation.

    opened by belugabehr 0
Releases(v2.2.2)
  • v2.2.2(Nov 11, 2018)

    This maintenance release improves life of Bazel users (no more "config.h" leaking into global include paths), fixes build with recent MinGW versions, and silences a number of static code analyzer and compiler warnings. The build targets exported by the CMake configuration of this library are now also prefixed by the package name "gflags::" following a more recent (unwritten) CMake convention. The unprefixed target names are still supported to avoid that dependent projects have to be modified due to this change in imported target names.

    For a full list of changes, see the closed issues of v2.2.2 Milestone.

    Source code(tar.gz)
    Source code(zip)
    gflags-2.2.2.tar.gz.asc(496 bytes)
    gflags-2.2.2.zip.asc(496 bytes)
  • v2.2.1(Jul 11, 2017)

    Maintenance release with mainly Windows build fixes.

    • Link to online documentation in README
    • #194: Include utils by file instead of CMAKE_MODULE_PATH search
    • #195: Remove unused program_name variable
    • #196: Enable language C for older CMake versions when needed
    • #202: Changed include directory in bazel build
    • #207: Mark single argument constructors in mutex.h as explicit
    • #209: Use inttypes.h on VC++ 2013 and later
    • #212: Fix statically linked gflags library with MSVC
    • #213: Modify installation paths on Windows for vcpkg
    • #215: Fix static initialization order fiasco caused by global registry lock
    • #216: Fix use of ARGC in CMake macros
    • #222: Static code analyzer error regarding strncmp with empty kRootDir
    • #224: Check HAVE_STDINT_H or HAVE_INTTYPES_H for older MSVC versions
    Source code(tar.gz)
    Source code(zip)
    gflags-2.2.1.tar.gz.asc(522 bytes)
    gflags-2.2.1.zip.asc(522 bytes)
  • v2.2.0(Nov 25, 2016)

    This release adds support for use of the gflags library as external dependency not only in projects using CMake, but also Bazel, or pkg-config. One new minor feature is added in this release: when a command flag argument contains dashes, these are implicitly converted to underscores. This is to allow those used to separate words of the flag name by dashes to do so, while the flag variable names are required to use underscores.

    Memory leaks reported by valgrind should be resolved by this release. This release fixes build errors with MS Visual Studio 2015.

    Please report any further issues with this release using the GitHub issue tracker.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.2(Mar 24, 2015)

    This release completes the namespace change fixes. In particular, it restores binary ABI compatibility with release version 2.0. The deprecated "google" namespace is by default still kept as primary namespace while symbols are imported into the new "gflags" namespace. This can be overridden using the CMake variable GFLAGS_NAMESPACE.

    Other fixes of the build configuration are related to the (patched) CMake modules FindThreads.cmake and CheckTypeSize.cmake. These have been removed and instead the C language is enabled again even though gflags is written in C++ only.

    This release also marks the complete move of the gflags project from Google Code to GitHub. Email addresses of original issue reporters got lost in the process. Given the age of most issue reports, this should be negligable.

    Please report any further issues using the GitHub issue tracker.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.1(Mar 30, 2014)

    This release fixes a few bugs in the configuration of gflags_declare.h and adds a GFLAGS_INCLUDE_DIR variable to the build configuration. Setting GFLAGS_NAMESPACE to "google" no longer changes also the include path of the public header files. This allows the use of the library with other Google projects such as glog which still use the deprecated "google" namespace for the gflags library, but include it as "gflags/gflags.h".

    Source code(tar.gz)
    Source code(zip)
  • v2.1.0(Mar 20, 2014)

    The major changes are the use of CMake for the build configuration instead of the autotools and packaging support through CPack. This release compiles with all major compilers without warnings and passed the unit tests on Ubuntu 12.04, Windows 7 (Visual Studio 2008 and 2010, Cygwin, MinGW), and Mac OS X (Xcode 5.1).

    The binary packages contain optimized shared libraries only, while the dev(el) packages contain optimized static and shared libraries as well as the header files. No debug libraries are included. (Both DEB and RPM packages were created on Ubuntu 12.04)

    Source code(tar.gz)
    Source code(zip)
    gflags-2.1.0-1.amd64.rpm(128.43 KB)
    gflags-2.1.0-1.i386.rpm(129.16 KB)
    gflags-2.1.0.dmg(234.82 KB)
    gflags-devel-2.1.0-1.amd64.rpm(274.70 KB)
    gflags-devel-2.1.0-1.i386.rpm(265.73 KB)
    gflags-devel-2.1.0.dmg(260.38 KB)
    libgflags-dev_2.1.0-1_amd64.deb(264.99 KB)
    libgflags-dev_2.1.0-1_i386.deb(254.91 KB)
    libgflags0_2.1.0-1_amd64.deb(118.62 KB)
    libgflags0_2.1.0-1_i386.deb(119.24 KB)
Owner
gflags
Open Source gflags library
gflags
a version of lolcat with options for some lgbtq+ flags

queercat a version of lolcat with some lgbtq+ pride flags options Usage $ queercat [-f flag_number][-h horizontal_speed] [-v vertical_speed] [--] [FIL

null 39 Sep 9, 2022
This contains code and relevant schematics from my Applied Digital Signal Processing class, where we developed various digital filters on the NXP FRDM K22F development board.

#dsp_class Summary This repo is meant to hold any of the C and MATLAB programming I did over the course of my Applied Digital Signal Processing class

Abdullah Almosalami 1 Nov 11, 2021
This repository contains the source code of the project(StereoCraft) that we have developed for the Mixed Reality Hackathon organized by Microsoft using StereoKit SDK

StereoCraft - A block-building like experience built using StereoKit This repository contains the source code of the project that we have developed fo

G Bhanuteja 2 Dec 23, 2021
ncpaprop, a command-line package for modeling the propagation of low-frequency acoustic waves in the atmosphere.

ncpaprop ncpaprop is a software package aiming at providing a comprehensive set of tested and validated numerical models for simulating the long range

Claus Hetzer 7 Mar 14, 2022
Windows Package Manager CLI (aka winget)

Welcome to the Windows Package Manager Client (aka winget.exe) repository This repository contains the source code for the Windows Package Manager Cli

Microsoft 17.8k Sep 21, 2022
A simple header-only C++ argument parser library. Supposed to be flexible and powerful, and attempts to be compatible with the functionality of the Python standard argparse library (though not necessarily the API).

args Note that this library is essentially in maintenance mode. I haven't had the time to work on it or give it the love that it deserves. I'm not add

Taylor C. Richberger 1k Sep 18, 2022
A simple header-only C++ argument parser library. Supposed to be flexible and powerful, and attempts to be compatible with the functionality of the Python standard argparse library (though not necessarily the API).

args Note that this library is essentially in maintenance mode. I haven't had the time to work on it or give it the love that it deserves. I'm not add

Taylor C. Richberger 896 Aug 31, 2021
A library for interactive command line interfaces in modern C++

cli A cross-platform header only C++14 library for interactive command line interfaces (Cisco style) Features Header only Cross-platform (linux and wi

Daniele Pallastrelli 851 Sep 17, 2022
PDCurses - a curses library for environments that don't fit the termcap/terminfo model.

Welcome to PDCurses! PDCurses is an implementation of X/Open curses for multiple platforms. The latest version can be found at: https://pdcurses.org/

William McBrine 800 Sep 19, 2022
Library for writing text-based user interfaces

IMPORTANT This library is no longer maintained. It's pretty small if you have a big project that relies on it, just maintain it yourself. Or look for

null 1.9k Sep 17, 2022
Small header only C++ library for writing multiplatform terminal applications

Terminal Terminal is small header only library for writing terminal applications. It works on Linux, macOS and Windows (in the native cmd.exe console)

Jupyter Xeus 238 Sep 22, 2022
A single header C++ library for parsing command line arguments and options with minimal amount of code

Quick Arg Parser Tired of unwieldy tools like getopt or argp? Quick Arg Parser is a single header C++ library for parsing command line arguments

null 46 Aug 10, 2022
A command parsing library

LampOpt操作文档 概述 LampOpt是一个基于C++的控制台命令解析库,优点是体型小、适应全平台、方便易用。 引用 可选择在IDE中直接在引用目录中添加odt.h,或直接与需编译文件放在同一目录下,并引用: #include "odt.h" 使用 odt.h头文件内定义了一个名为LampOp

东灯 1 Aug 21, 2022
null 77 Aug 15, 2022
A C, C++ and Rust library to draw graphics with pixels in the terminal

A library to draw graphics with pixels in the terminal Who needs a GUI when you have a terminal ? Building To generate libpluto.a, run: $ make To ins

null 67 Sep 3, 2022
A (relatively) small node library to clone and pull git repositories in a standalone manner thanks to libgit2, powered by WebAssembly and Emscripten

simple-git-wasm A (relatively) small node library to clone and pull git repositories in a standalone manner thanks to libgit2, powered by WebAssembly

Powercord 20 May 20, 2022
A single-class C++ library for reading animated GIF files

EasyGifReader EasyGifReader is a single-class C++ library that aims to simplify reading an animated GIF file. It is built on top of and depends on gif

Viktor Chlumský 7 Sep 3, 2022
Library for creating terminal applications with text-based widgets

Library for creating terminal applications with text-based widgets FINAL CUT is a C++ class library and widget toolkit with full mouse support for cre

Markus Gans 670 Sep 17, 2022
C++ Library for pulling system and hardware information, without hitting the command line.

infoware C++ Library for pulling system and hardware information, without hitting the command line. Requirements No non-built-in ones by default. Some

The Phantom Derpstorm 308 Sep 17, 2022