sharper/gflags

Automatically exported from code.google.com/p/gflags

gflags's Issues

Put public headers in include/ instead of src/

In the 1.0-rc1 source archive, the public header files are located in 
src/ rather than in the traditional include/ directory. This is only a 
minor problem, but I think the source tree would be easier to navigate if 
the interface is separated from the implementation at the top level.

Original issue reported on code.google.com by [email protected] on 29 Aug 2008 at 10:57

valgrind reports 'potential memory leaks' from gflags

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.

Original issue reported on code.google.com by [email protected] on 13 Dec 2010 at 9:23

setup.py needed in root directory for pip / easy_install

In order to easily install gflags via pip or easy_install, a tgz with 
setup.py in the root directory seems to be needed.

Can you please either update the existing package or package a python only 
version of gflags so that it can be pulled in via pip or easy_install.

I tried searching for a way to tell pip to use setup.py in a subdirectory of 
an archive, but couldn't seem to find anything.

Original issue reported on code.google.com by [email protected] on 1 Nov 2009 at 11:11

x64 platform for Google Flags on Windows

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.

Original issue reported on code.google.com by [email protected] on 9 Jul 2010 at 3:57

Customize default --help message

Hi all,

is there any way of improving/customizing the regular --help message? The
default --help shows the help message for all flags, including the gflags
flags, and plus, it separates the flags for modules, as in the example below:

 Flags from /home/user/Main.cpp:
   -a (some description) type:...
   -f ....

So, if i'm using only one module is look strange.. 

Is there any way of making help printing only my flags independent from
which modules the flags are? And plus, the usage message comes before the
help message.. is there any way of making it to come after? 

I couldn't find anything  to help on those issues looking at gflags.h and
in the gflags help...

thanks...

Pablo

Original issue reported on code.google.com by [email protected] on 7 Jan 2010 at 4:01

Comparison between signed and unsigned types

What steps will reproduce the problem?
1. Configure C++ compiler to treat all warnings as errors
2. Compile gflags

What is the expected output? What do you see instead?
Compiled code. Error: comparison between signed and unsigned integer
expressions

What version of the product are you using? On what operating system?
gflags-0.8. Ubuntu 8.04.

Please provide any additional information below.
Hey Craig, all,
 Probably not a big issue, obviously easy to fix, but I'm using gflags in
an environment where there were a few changes that had to be made before it
would be compiled properly (detailed above). I've attached a patch, though
it only touches gflags.cc and gflags_reporting.cc, and no unit tests.
Furthermore, I fixed gflags_reporting.cc by converting just one unsigned
type to signed, when it really makes more sense to change all values that a
sign doesn't make sense on to unsigned, such as kLineLength.
:)

Original issue reported on code.google.com by jtolds on 2 Jul 2008 at 3:54

Attachments:

• gflags.patch

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

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.

Original issue reported on code.google.com by [email protected] on 26 Feb 2011 at 9:44

gflags segfaults in google::ParseCommandLineFlags

What steps will reproduce the problem?
1. Compile the program listed below
2. Run it
3. Segfault

Test program I created:
#include <iostream>
#include <string>
#include <google/gflags.h>

DEFINE_bool(foo, false, "is foo true?");
DEFINE_string(name, "", "user name");

int main(int argc, char **argv) {
  google::ParseCommandLineFlags(&argc, &argv, true);
  if (!FLAGS_name.empty()) {
    std::cout << "Your name is " << FLAGS_name << std::endl;
  }

  if (FLAGS_foo) {
    std::cout << "Foo is true\n";
  }

  return 0;
}

Running the program through valgrind gives the following errors:

=3819== Jump to the invalid address stated on the next line
==3819==    at 0x0: ???
==3819==    by 0x43EBAF9: google::FlagRegisterer::FlagRegisterer(char
const*, char const*, char const*, char const*, void*, void*) (gflags.cc:667)
==3819==    by 0x43F53AC: __static_initialization_and_destruction_0(int,
int) (gflags_reporting.cc:68)
==3819==    by 0x43F8320: (within /usr/lib/libgflags.so.0.0.0)
==3819==    by 0x43E9F50: (within /usr/lib/libgflags.so.0.0.0)
==3819==    by 0x441D32AA: call_init (in /lib/ld-2.3.6.so)
==3819==    by 0x441D335C: _dl_init (in /lib/ld-2.3.6.so)
==3819==    by 0x441C87CE: (within /lib/ld-2.3.6.so)
==3819==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3819==
==3819== Process terminating with default action of signal 11 (SIGSEGV)
==3819==  Bad permissions for mapped region at address 0x0
==3819==    at 0x0: ???
==3819==    by 0x43EBAF9: google::FlagRegisterer::FlagRegisterer(char
const*, char const*, char const*, char const*, void*, void*) (gflags.cc:667)
==3819==    by 0x43F53AC: __static_initialization_and_destruction_0(int,
int) (gflags_reporting.cc:68)
==3819==    by 0x43F8320: (within /usr/lib/libgflags.so.0.0.0)
==3819==    by 0x43E9F50: (within /usr/lib/libgflags.so.0.0.0)
==3819==    by 0x441D32AA: call_init (in /lib/ld-2.3.6.so)
==3819==    by 0x441D335C: _dl_init (in /lib/ld-2.3.6.so)
==3819==    by 0x441C87CE: (within /lib/ld-2.3.6.so)
==3819==    by 0x0: ???
==3819==    by 0x43A0CAF: ???
==3819==    by 0xA: ???
==3819==    by 0x0: ???
==3819==
==3819== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 1)
==3819== malloc/free: in use at exit: 48 bytes in 3 blocks.
==3819== malloc/free: 3 allocs, 0 frees, 48 bytes allocated.
==3819== For counts of detected errors, rerun with: -v
==3819== searching for pointers to 3 not-freed blocks.
==3819== checked 145,820 bytes.
==3819==
==3819== LEAK SUMMARY:
==3819==    definitely lost: 0 bytes in 0 blocks.
==3819==      possibly lost: 0 bytes in 0 blocks.
==3819==    still reachable: 48 bytes in 3 blocks.
==3819==         suppressed: 0 bytes in 0 blocks.
==3819== Reachable blocks (those to which a pointer was found) are not shown.
==3819== To see them, rerun with: --show-reachable=yes

What version of the product are you using? On what operating system?
Version 0.5 on Linux
uname snippet:
2.6.18.5-gg10-mixed64-32 #1 SMP Tue May 8 22:29:42 PDT 2007 x86_64 GNU/Linux

Original issue reported on code.google.com by [email protected] on 13 Aug 2007 at 7:37

Python implementation missing from source archive

What steps will reproduce the problem?
1. Download gflags-0.2.tar.gz
2. Extract archive.

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

Expected to find the python implementation in the python/ subdir,
as mentioned in the documentation. However, it's missing from
the archive.

Original issue reported on code.google.com by [email protected] on 28 Mar 2007 at 4:14

Bug with using --help for description longer than 128 bytes.

What steps will reproduce the problem?
1. Compile version 1.6 using Visual Studio 2008
2. Create a simple main.cpp program as follows:

#include <gflags/gflags.h>
int main(int argc, char* argv[])
{
    google::ParseCommandLineFlags(&argc, &argv, true);
    return 0;
}

3. Run it with "--help" as the argument.

What is the expected output? What do you see instead?
It will blow up on the first assert in 
gflags_reporting.cc:DescribeOneFlag(const CommandLineFlagInfo& flag).

This is because the flag.description is truncated in SStringPrintf, since the 
util.h:InternalStringPrintf() contains a bug.

Basically the space[128] buffer is reused wrongly in the second loop, which 
tries to reformat the string with a bigger buffer. Instead of using 
  vsnprintf(buf, length, ...)
it is
  vsnprintf(space, length, ...)

Which uses the wrong buffer.

What version of the product are you using? On what operating system?
This bug should be present on most platforms as far as I can tell from the 
code. Basically, it will currently blow up when running "--help" where the 
description is longer than 128 bytes.

Please provide any additional information below.

A patch is attached.

Original issue reported on code.google.com by [email protected] on 16 Aug 2011 at 12:12

• Merged into: #47

Attachments:

• gflags-util-h.patch

Documentation uses old header name

In the 1.0-rc1 version of gflags.html, the header is still included from 
the old path:
#include <google/gflags.h>

Original issue reported on code.google.com by [email protected] on 29 Aug 2008 at 10:36

ChangeLog and NEWS files should be swapped

Received a reply from debian-mentors that the NEWS and ChangeLog files
should be swapped since ChangeLog appears to be release specific updates:

http://www.gnu.org/prep/standards/standards.html#NEWS-File
http://www.gnu.org/prep/standards/standards.html#Change-Logs

Original issue reported on code.google.com by [email protected] on 30 Apr 2010 at 3:16

test suite fails on x86_64

My kernel is 2.6.26-0.115.rc9.git2.fc10.x86_64

I have packaged it from fedora, but 2 out of 17 test cases fail on latest
rawhide.

I will try to look into, if I can look why it is failling and will provide
log ASAP.


Thanks,

Original issue reported on code.google.com by [email protected] on 10 Sep 2008 at 3:51

gflags.cc should include <stdio.h>

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

gflags 0.3-2, Debian Linux testing, kernel 2.4.27, glibc 2.3.6, gcc 2.95.4

Please provide any additional information below.

I admit my environment is too old.  But gflags.cc should include <stdio.h>
at least for snprintf().

Original issue reported on code.google.com by [email protected] on 29 Mar 2007 at 8:00

--helpshort, --helpon, --helppackage don't function properly

What steps will reproduce the problem?

For any gflags program do:

test_prog --helpshort
test_prog --helpon something
test_prog --helppackage

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

The expected output is detailed in the how-to.  For --helpshort and
--helpon, I get "No modules matched: use -help" For --helppackage I get
"WARNING: Unable to find a package for file=gflags_test"

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

Both rc1 download and SVN have the problem.

Please provide any additional information below.

In void HandleCommandLineHelpFlags in gflags_reporting.cc, you
generates substrings to test using the program name prepended by a '/'
and followed by different extensions.  You then test that against the
program name with the leading path (and all the '/' characters)
stripped off.  As a result, it will never find any matches, which make
--helpshort, --helpon, and --helppackage always fail.  You can fix this by
deleting the '/' characters in the substrings you push, or by adding a '/'
to the program name you test.

Original issue reported on code.google.com by [email protected] on 9 Sep 2008 at 2:32

Missing "std::" in DECLARE_string

In 1.0-rc1's version of gflags.h, DECLARE_string is defined as follows:
#define DECLARE_string(name)  namespace fLS { extern string& 
FLAGS_##name; } \
                              using fLS::FLAGS_##name

It should use "std::string" instead of just "string". Some compilers 
accept plain "string" as well, but recent versions of GCC no longer 
accept it.

The unit test won't catch this because DECLARE_string is a macro and 
gflags_unittest_main.cc contains a "using std::string;" before it starts 
declaring flags.

Original issue reported on code.google.com by [email protected] on 29 Aug 2008 at 4:36

src/gflags_unittest.cc should include <cstdlib>

It seems that src/gflags_unittest.cc should #include <cstdlib> as it uses
the "exit" syscall.

I picked this up when comping with GCC 4.3.0:
src/gflags_unittest.cc: In static member function 'static void
google::Test_ReadFlagsFromStringDeathTest_HelpMatch::RunTest()':
src/gflags_unittest.cc:215: error: 'exit' was not declared in this scope
etc.

Original issue reported on code.google.com by [email protected] on 19 Mar 2008 at 3:15

Running make fails on Mac OS X

I got this error when running "make" after a successful "configure".

/bin/sh ./libtool --tag=CXX --mode=link g++ -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -g -O2 -no-undefined   -o
libgflags.la -rpath /usr/local/lib -D_THREAD_SAFE   libgflags_la-gflags.lo
libgflags_la-gflags_reporting.lo libgflags_la-gflags_completions.lo  
rm -fr  .libs/libgflags.0.0.0.dylib .libs/libgflags.0.0.0.dylib.dSYM
.libs/libgflags.0.dylib .libs/libgflags.a .libs/libgflags.dylib
g++ -dynamiclib  -o .libs/libgflags.0.0.0.dylib 
.libs/libgflags_la-gflags.o .libs/libgflags_la-gflags_reporting.o
.libs/libgflags_la-gflags_completions.o   -install_name 
/usr/local/lib/libgflags.0.dylib -Wl,-compatibility_version -Wl,1
-Wl,-current_version -Wl,1.0 
dsymutil .libs/libgflags.0.0.0.dylib || :
(cd .libs && rm -f libgflags.0.dylib && ln -s libgflags.0.0.0.dylib
libgflags.0.dylib)
(cd .libs && rm -f libgflags.dylib && ln -s libgflags.0.0.0.dylib
libgflags.dylib)
ar cru .libs/libgflags.a  libgflags_la-gflags.o
libgflags_la-gflags_reporting.o libgflags_la-gflags_completions.o
ar: temporary file: No such file or directory
make: *** [libgflags.la] Error 1

The problem is when making "libgflags.la" as can be seen above.

Original issue reported on code.google.com by [email protected] on 19 Oct 2009 at 3:00

Read-only files in source tarball

Many (but not all) files in gflags-1.0rc1.tar.gz to do have write 
permission set for the file owner. Was this done intentionally or is it a 
side effect of the packaging process?

Original issue reported on code.google.com by [email protected] on 29 Aug 2008 at 11:51

suggestion: namespaces

If instead of prefixing flags with FLAGS_ the DEFINE_* would define them in 
the current namespace, user could give them more meaningful prefixes, 
e.g. on per subsystem basis. And while "inside" subsystem namespace we 
won't have to type the prefix.

This suggestion still isn't perfect (for example it might make it appear that 
user can create the same flag in different namespaces, like foo:quiet and 
bar::quiet, which is not true as both correspond to -quiet) but I just wanted 
to start the discussion to figure out what would be the best solution or 
may be to be convinced that the current solution is perfect :)

// something like (beware: pseudocode++)

namespace foo {
   DEFINE_bool(quiet, false, "shut up");
}
...
namespace foo {
   DECLARE_bool(quiet);
}

...

main() {
  if (!foo::quiet) {
    std::cout << "Hello, world!";
  }
}

...

namespace foo {
  void bar() {
    if (!quiet) {
      make_noise();
    }
  }
}

Original issue reported on code.google.com by [email protected] on 18 Feb 2010 at 9:00

DEFINE_string does not work if string is not in global namespace

What steps will reproduce the problem?
1.

a.cc:

#include <google/gflags.h>

DEFINE_string(example, "314", "example");

int main(int argc, char** argv) {
  google::ParseCommandLineFlags(&argc, &argv, true);
}

2.

g++ -o a.o -c a.cc

3.

What is the expected output? What do you see instead?
Should compile, instead:
a.cc:3: error: expected initializer before '*' token
a.cc:3: error: 'FLAGS_noexample' was not declared in this scope

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

glags 0.9
ubuntu 7.10 
g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

Please provide any additional information below.

some std:: are missing from gflags.h, gflags.h.in etc. This is a problem if
string is not declared in global namespace by using namespace std or using
std::string. 

Original issue reported on code.google.com by [email protected] on 13 Aug 2008 at 10:44

python installer fails

What steps will reproduce the problem?
1. cd python
2. sudo python setup.py install
3.

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

   Expected:
running install
running build
running build_py
running install_lib
running install_data

   Got:
running install
running build
running build_py
running install_lib
running install_data
warning: install_data: setup script did not provide a directory for '/usr/
local/bin' -- installing right in '/usr/local'
error: can't copy '/usr/local/bin': doesn't exist or not a regular file


What version of the product are you using? On what operating system?
gflags-0.4 on Redhat Enterprise Linux 4

Please provide any additional information below.

From what I can tell, it looks like a line in the setup.py file should be 
changed:

  current:
      data_files=["gflags2man.py"])
  change to:
      data_files=[ ("/usr/local/bin", ["gflags2man.py"])  ]

Original issue reported on code.google.com by [email protected] on 12 Jun 2007 at 9:51

build fails if the src directory is on a netapp and the build output directory is distinct from the src dir

What steps will reproduce the problem?

i checked out a perforce client containing gflags onto my homedir (NFS, 
netapp).  build fails in 
gflags as follows:

...
rm -f src/gflags_unittest-main.cc
cp -p src/gflags_unittest.cc src/gflags_unittest-main.cc
cp: cannot stat `src/gflags_unittest.cc': No such file or directory
make[1]: *** [src/gflags_unittest-main.cc] Error 1


build works fine when the client is on ext3.
i'm building with a separate build output directory - i.e. running
the configure script from a directory different from the src dir.
the build output is also different in that it's on ext3 while the
src is on NFS to a netapp.  the netapp connection is relevant because
it maintains micro-second timestamps on files while ext3 only has
1-second resolution.  at 1-second resolution, these files are "never"
considered out-of-date, so the buggy rule is never triggers.

this seems to be a problem related to VPATH: a couple of the recipes
use exact paths to dependencies instead of using make variables for
them, so the VPATH case doesn't work.

here's a patch to fix it:


==== //depot3/platforms/patched_vendor_src/gflags/Makefile.in#1 - 
/local/caveh/sc-
p3/platforms/patched_vendor_src/gflags/Makefile.in ====
*** 
/tmp/g4-87397/cache/depot3/platforms/patched_vendor_src/gflags/Makefile.in#1    
    Wed Oct 28 
18:29:06 2009
--- 
/tmp/g4-87397/4111716/depot3/platforms/patched_vendor_src/gflags/Makefile.in    
    Thu Oct 29 
17:51:04 2009
***************
*** 1064,1073 ****

  src/gflags_unittest-main.cc: src/gflags_unittest.cc
        rm -f src/gflags_unittest-main.cc
!       cp -p src/gflags_unittest.cc src/gflags_unittest-main.cc
  src/gflags_unittest_main.cc: src/gflags_unittest.cc
        rm -f src/gflags_unittest_main.cc
!       cp -p src/gflags_unittest.cc src/gflags_unittest_main.cc
  gflags_unittest_sh: gflags_unittest$(EXEEXT) \
                      gflags_unittest2$(EXEEXT) \
                      gflags_unittest3$(EXEEXT)
--- 1064,1073 ----

  src/gflags_unittest-main.cc: src/gflags_unittest.cc
        rm -f src/gflags_unittest-main.cc
!       cp $< src/gflags_unittest-main.cc
  src/gflags_unittest_main.cc: src/gflags_unittest.cc
        rm -f src/gflags_unittest_main.cc
!       cp $< src/gflags_unittest_main.cc
  gflags_unittest_sh: gflags_unittest$(EXEEXT) \
                      gflags_unittest2$(EXEEXT) \
                      gflags_unittest3$(EXEEXT)

Original issue reported on code.google.com by [email protected] on 30 Oct 2009 at 12:59

Add pkg-config support

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

Original issue reported on code.google.com by [email protected] on 23 Sep 2010 at 3:11

src/solaris/libstdc++.la is in the 1.1 tarball, but is not checked into svn

With this file missing, the code doesn't build.

http://code.google.com/p/google-gflags/source/browse/#svn/trunk/src/solaris 
shows the directory is empty.

If I download and unpack http://google-gflags.googlecode.com/files/gflags-
1.1.tar.gz, the directory contains libstdc++.la.

(I suspect the file was missed because svn excludes .la files by default.)

Original issue reported on code.google.com by [email protected] on 17 Jul 2009 at 7:51

Special "debug mode" logging macros have always effect, even if NDEBUG macro is defined

What steps will reproduce the problem?
1. define macro NDEBUG
2. use Special "debug mode" logging macros in an application
3. launch compiled application

What is the expected output? What do you see instead?
The expected output is that logging in debug mode should not appear.
Instead it does.

What version of the product are you using? On what operating system?
Google-gflags 1.6 on Debian unstable (linux kernel 3.0.0-1-amd64)

Please provide any additional information below.
g++ compiler version 4.6

Original issue reported on code.google.com by [email protected] on 28 Aug 2011 at 9:23

ReportError doesn't flush stderr before exiting, swallowing error output

In gflags.cc:207's ReportError function exit(1) gets called without flushing 
stderr, so the error message doesn't necessarily get printed to the console. 
Needless to say, this is very annoying for your end users. :-)

Simple fix is to add this line after va_end(ap); :
fflush(stderr);

This is an issue under Cygwin's BASH, for example (although the cmd.exe prompt 
in Windows seems to output it OK).

Original issue reported on code.google.com by alastair.maw on 20 May 2011 at 1:20

64 bit integer conversion type

What steps will reproduce the problem?
1. Configure your C++ compiler to treat all warnings as errors
2. Build on a 64 bit machine
3. Compile gflags

What is the expected output? What do you see instead?
Compiled code.
cc1plus: warnings being treated as errors
gflags.cc: In member function 'std::string google::FlagValue::ToString()
const':
gflags.cc:251: warning: format '%lld' expects type 'long long int', but
argument 4 has type 'long int'
gflags.cc:251: warning: format '%lld' expects type 'long long int', but
argument 4 has type 'long int'
gflags.cc:254: warning: format '%llu' expects type 'long long unsigned
int', but argument 4 has type 'long unsigned int'
gflags.cc:254: warning: format '%llu' expects type 'long long unsigned
int', but argument 4 has type 'long unsigned int'

What version of the product are you using? On what operating system?
gflags-0.8. Debian Etch.

Please provide any additional information below.
This error does not occur on 32 bit strict build systems, but it does on 64
bit.
Lines 251 and 254 in my version of gflags are as follows:

snprintf(intbuf, sizeof(intbuf), "%lld", VALUE_AS(int64));
snprintf(intbuf, sizeof(intbuf), "%llu", VALUE_AS(uint64));

Original issue reported on code.google.com by jtolds on 2 Jul 2008 at 8:03

Internal compiler error in GCC 4.2.1

If I compile gflags 1.0-rc1 with GCC 4.2.1 (SUSE Linux 10.3, x86) and 
debug symbols enabled ("-g"), GCC crashes with the following message:

src/gflags.cc:158: internal compiler error: in reference_to_unused, at 
dwarf2out.c:10010

I also tried GCC 4.3.2 and then it compiles just fine, so it seems the 
bug in GCC is fixed already. However, there are probably still a lot of 
broken compilers installed, so maybe it would be a good idea to put a 
workaround in gflags.

The problem occurs on any use of DEFINE_string, so not only when building 
gflags itself, but also when building an application that uses gflags. It 
happens only when "-g" is passed to GCC, so the problem is most likely in 
the generation of the debug symbols ("dwarf2out.c" also suggests this).

I discovered that if DECLARE_string is used before DEFINE_string with the 
same flag name, GCC does not crash. So a possible workaround would be to 
include the contents of the DECLARE_string macro at the start of the 
DEFINE_string macro as well.

Original issue reported on code.google.com by [email protected] on 29 Aug 2008 at 5:54

Using DEFINE_string causes error in optimized compiles

What steps will reproduce the problem?

Compile a C++ file that uses DEFINE_string with g++ 4.4.1. Use the -O2 flag 
while compiling.


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

The expectation is that the file should compile without any warnings or 
errors. Instead, here is the error that g++ emits:

error: dereferencing type-punned pointer will break strict-aliasing rules

One can get rid of this error by using the -fno-strict-aliasing flag while 
compiling, but using this makes the optimization algorithms less effective.  
It'll be great if the next release of gflags could fix the DEFINE_string 
macro to be more compiler friendly instead.

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

gflags 1.2. Ubuntu 9.10.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 8 Jan 2010 at 9:10

don't work with VCExpress 9.0

don't work with VCExpress 9.0

Original issue reported on code.google.com by [email protected] on 31 Jul 2009 at 6:52

Java Version

After C and python, a Java version would be desirable. 

Original issue reported on code.google.com by yukuku on 3 Apr 2008 at 7:33

Using command line form "-something false" doesn't work for a bool flag

What steps will reproduce the problem?

#include <stdio.h>
#include <google/gflags.h>

DEFINE_bool (something, true, "Set this for something.");

int main(int argc, char **argv)
{
 google::ParseCommandLineFlags(&argc, &argv, true);

 fprintf(stderr, "FLAGS_something = %d\n", FLAGS_something);
 return 0;
}

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

According to the how-to, the following:

test_prog --nosomething
test_prog --something=false
test_prog --something false
test_prog -nosomething
test_prog -something=false
test_prog -something false

should all set the something flag to false.  The ones with a space
between the flag and the argument to the flag do not work.  Spaces
work for the other types (at least double and string) but not bool.  I
realize that the preferred syntax is --something/--nosomething but the
docs say that the spaces are OK.

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

The rc1 download and the SVN version both have the same problem.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 9 Sep 2008 at 2:18

how to support default parameter?

how to support default parameter in command line? like

ping www.qq.com

Original issue reported on code.google.com by [email protected] on 22 Jan 2011 at 6:59

--home option for python setup.py install ignored

What steps will reproduce the problem?
1. python setup.py install --home="/Some/non-standard/directory/location

What is the expected output? What do you see instead?
gflags2man.py attempted to install in /usr/local/bin/.  I would prefer it
also be installed in the directory specified by --home.

What version of the product are you using? On what operating system?
I am using version 0.6 on Mac-OSX version 10.4.10

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 26 Sep 2007 at 4:19

Allow users to categorize flags

This is a subset of issue 32, but an easily-solved subset. :)

The ability to swap out the "filename" with an application-specific
category allows a library to use knowledge of its structure to
better organize the flags.

For each DEFINE_type macro, this patch defines a DEFINE_CATEGORY_type 
macro that takes a category argument. This category argument defaults 
to __FILE__, as before, to avoid breaking existing code.

This also makes a test (which previously poked into the internals) use the
new macro.

The second patch makes a simple change for future-proofing; it adds a
category field to CommandLineFlagInfo which avoids the (currently noop) 
CleanFilename processing. Your call whether you think this is important.

What this patch does NOT do is s/filename/category/ most of the library.
The clarity argument says "do it" and the useless change argument says 
"don't". I'll leave the design decision up to you.

Original issue reported on code.google.com by [email protected] on 25 Aug 2010 at 1:48

Attachments:

• 0001-Replace-the-flag-filename-with-a-category.patch
• 0002-Add-a-category-field-to-CommandLineFlagInfo.patch

gflags 0.8 does not build on OpenSUSE 10.3

What steps will reproduce the problem?
1. run ./configure in source dir without any parameters
2. run make


What is the expected output? What do you see instead?
Expected success in building the libraries, instead I got:
if /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -
I./src  -I./src   -DNDEBUG -g -O2 -MT libgflags_la-gflags.lo -MD -MP -MF 
".deps/libgflags_la-gflags.Tpo" -c -o libgflags_la-gflags.lo `test -f 'src/
gflags.cc' || echo './'`src/gflags.cc; \
        then mv -f ".deps/libgflags_la-gflags.Tpo" ".deps/libgflags_la-
gflags.Plo"; else rm -f ".deps/libgflags_la-gflags.Tpo"; exit 1; fi
 g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -DNDEBUG -g -O2 -MT 
libgflags_la-gflags.lo -MD -MP -MF .deps/libgflags_la-gflags.Tpo -c src/
gflags.cc  -fPIC -DPIC -o .libs/libgflags_la-gflags.o
src/gflags.cc:75: internal compiler error: in reference_to_unused, at 
dwarf2out.c:10010
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugs.opensuse.org> for instructions.
make: *** [libgflags_la-gflags.lo] Error 1


What version of the product are you using? On what operating system?
Tried to build gflags 0.8 from source tarball on OpenSUSE 10.3 with
yaar@yaro:~/Download/gflags-0.8> g++ -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-
local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man -
-libdir=/usr/lib --libexecdir=/usr/lib --enable-
languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --
with-gxx-include-dir=/usr/include/c++/4.2.1 --enable-ssp --disable-libssp -
-disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-shared --
enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-
pch --program-suffix=-4.2 --enable-version-specific-runtime-libs --without-
system-libunwind --with-cpu=generic --host=i586-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 24 Apr 2008 at 3:26

Long doc strings show up garbled with --help

What steps will reproduce the problem?
1. Define command line flags with a long doc string (at least 200 chars)
2. Compile and run the binary with --help or --helpshort
3. Notice how the doc strings come up garbled

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

The doc strings should not be garbled. 

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

gflags-1.6. Ubuntu 10.10, x86_64 platform.

Please provide any additional information below.

I'm attaching a .cc file that demonstrates the problem. Here is the output when 
I compile this file with gflags-1.6 and run it with argument --helpshort:

  Flags from /home/aron/gflags_bug.cc:
    -bar (This is the first line of the bar command line argument. This is the
      second line of the bar command line argument. Th    -foo (This is the first line of the foo command line argument. This is the
      second line of the foo command line argument. Th


I'd like to add that the bug didn't exist in gflags-1.2. Here's the output when 
the same file is linked against gflags-1.2 and then compiled and run with 
--helpshort:

  Flags from gflags_bug.cc:
    -bar (This is the first line of the bar command line argument. This is the
      second line of the bar command line argument. This is the third line of
      the bar command line argument. ) type: int32 default: 1
    -foo (This is the first line of the foo command line argument. This is the
      second line of the foo command line argument. This is the third line of
      the foo command line argument. ) type: int32 default: 1

Original issue reported on code.google.com by [email protected] on 3 Aug 2011 at 7:13

Attachments:

• gflags_bug.cc

Add static lib building for VS2005

Our project, on windows using vs2005, needs to have all libs statically linked. 

I met some problems when I tried to make a static lib building for gflags. The 
main issue seems that, for static lib build, there's no need to 
dllexport/dllimport anything. There's already the macro GFLAGS_DLL_DECL to take 
care of all methods exported in library for this purpose, but for 
DECLARE_VARIABLE/DEFINE_VARIABLE macro, dllexport/dllimport is hard-coded, 
which causes problem. Note that the problem doesn't show up for unit test, 
because all things are in one compile unit. To see the problem, one example is 
to compile google-glog lib with gflags, as static lib of cause, in vs2005, and 
the linker will complain. (btw, maybe a unit test case for this situation is 
needed). 

Because of this, I intended to resolve it by adding 2 more macros, 
GFLAGS_VAR_DECLARE/GFLAGS_VAR_DEFINE, to control if we need dllexport/dllimport 
according to the build type(dll or lib). Also, I added 2 project files for 
static lib and static-link unittest, just like google-gflags does. The details 
are all in the attached patch. Note that I have to update all solution to 
vs2005 version, but I think it's easy to down-grade to vs2003 if you want to 
test. Also, I don't have resource to test if the patch affect linux build.

Hope that helps.

ps: sorry for my poor english, let code speaks...

Original issue reported on code.google.com by frank28 on 16 Aug 2010 at 10:30

Attachments:

• gflags_static_lib_vs.patch.zip

Build failure for arm-linux

What steps will reproduce the problem?
1. ./configure --host=arm-linux --target=arm-linux
--prefix=/usr/local/arm-linux/
2. make

What is the expected output? What do you see instead?
Expected output: no errors during make

output for glog-0.3.0 :
src/symbolize.cc: In function `ssize_t google::ReadPersistent(int, void*, 
   unsigned int)':
src/symbolize.cc:124: error: `SSIZE_MAX' undeclared (first use this function)
src/symbolize.cc:124: error: (Each undeclared identifier is reported only once 
   for each function it appears in.)
make: *** [libglog_la-symbolize.lo] Error 1

What version of the product are you using? On what operating system?
Fedora 11 64 bit
tool-chain arm-linux-g++ 3.2.2 

Please provide any additional information below.
As workaround I added this code to symbolize.cc :
#ifndef SSIZE_MAX
#define SSIZE_MAX 0x7fffffff
#endif

Original issue reported on code.google.com by [email protected] on 30 Oct 2009 at 6:53

Select subset of flags on startup / conditionally allow flags

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, "maximal number of lines to print");
    int main(int argc; char **argv) {
        if (argc >= 2 && !strcmp(argv[1], "print")) {
            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.

Original issue reported on code.google.com by [email protected] on 19 Jul 2011 at 3:11

unittest-main vs unittest_main

In the 1.0-rc1 source tree, there are two identical files:
Externals/gflags/src/gflags_unittest-main.cc
Externals/gflags/src/gflags_unittest_main.cc

All other files names use underscores, so my guess is the one with the 
dash is the result of a half-performed rename.

Original issue reported on code.google.com by [email protected] on 29 Aug 2008 at 10:59

python-gflags debian package does not exist

The debian packaging in  gflags-1.1/packages/deb does not contain the
gflags python module. I hacked on it a little bit to get something together
for a project here --
https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/708167/+listing-ar
chive-extra

Original issue reported on code.google.com by [email protected] on 26 Aug 2009 at 5:42

Why unrecognized flagnames are silently ignored in a flagfile

What steps will reproduce the problem?
1. write a wrong flag in a flagfile name : demo.flag
2. run a program using --flagfile=demo.flag
3. unrecognized flagnames are silently ignored,

What is the expected output? What do you see instead?
I see nothing and want the gflag notice me about the wrong flag .

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

Please provide any additional information below.

In particular, unrecognized flagnames are silently ignored, as are flags that 
are missing a required value (e.g., a flagfile that just says --languages).

Why?

Original issue reported on code.google.com by lshmouse on 3 Nov 2011 at 6:40

Problem linking under visual studio 10 C++ express, windows 7

What steps will reproduce the problem?
1. Compile the program under windows with visual studio 10
2.
3.

What is the expected output? What do you see instead?
It should compile. Instead it fails to link with the following message: (in 
french; sorry)

tmp2.obj : error LNK2019: symbole externe non résolu "__declspec(dllimport) 
int fLI::FLAGS_test" (__imp_?FLAGS_test@fLI@@3HA) référencé dans la fonction 
_main
tmp.exe : fatal error LNK1120: 1 externes non résolus

What version of the product are you using? On what operating system?
Visual studio 10 C++ express on windows 7 23 bit

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 7 Apr 2011 at 7:23

Attachments:

• test.mk
• tmp1.cc
• tmp2.cc

non-portable use of isnan/isinf math macros

isnan and isinf are macro's in mac os x. causing a failure when trying to
compile graph_unittest.cc. EXPECT_* macros make some non-portable
assumptions about is*.

BTW after a quick fix the unit test runs correctly!

Original issue reported on code.google.com by [email protected] on 25 Apr 2007 at 10:08

No example on wiki

Wiki should have an example of use.

Original issue reported on code.google.com by [email protected] on 1 Oct 2009 at 1:52

strtoq() and strtouq() are not portable

What steps will reproduce the problem?

1. On the platform which has no strtoq (e.g. Cygwin)
2. ./configure && make

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

Windows XP SP2, Cygwin 1.5.24

Please provide any additional information below.

I think strtoll() and strtoull() should be used instead.
Workaround:
# make CXXFLAGS="-Dstrtoq=strtoll -Dstrtouq=strtoull"

Original issue reported on code.google.com by [email protected] on 29 Mar 2007 at 3:50

config.sub and config.guess out of date

What steps will reproduce the problem?
1. ./configure

What is the expected output? What do you see instead?
Expect configure to be able to figure out the processor type, but instead it 
reports.

checking build system type... ./config.guess: unable to guess system type

This script, last modified 2007-07-22, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess
and
  http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <[email protected]> in order to provide the needed
information to handle your system.

config.guess timestamp = 2007-07-22



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

Version 1.4 on TILEPro64 running Linux.

Please provide any additional information below.

Updating to the latest config.sub and config.guess work.

Original issue reported on code.google.com by [email protected] on 15 Jan 2011 at 9:23

--helpshort complains about SetUsageMessage

What steps will reproduce the problem?
1. Compile any short program with gflags without calling SetUsageMessage
2. Run the program with --helpshort

What is the expected output? What do you see instead?
A list of flags from the file containing main() only.  Instead, an error
message states 'Warning: SetUsageMessage() never called'.  If the
usage message is set, then I see the message I set it with as expected.

What version of the product are you using? On what operating system?
Version 0.6, Ubuntu linux x86-64

Original issue reported on code.google.com by [email protected] on 31 Aug 2007 at 4:11