sharper / gflags Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/gflags
License: BSD 3-Clause "New" or "Revised" License
Automatically exported from code.google.com/p/gflags
License: BSD 3-Clause "New" or "Revised" License
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
Attachments:
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:
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:
don't work with VCExpress 9.0
Original issue reported on code.google.com by [email protected]
on 31 Jul 2009 at 6:52
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
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
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
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
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
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
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
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
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:
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
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
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
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
Wiki should have an example of use.
Original issue reported on code.google.com by [email protected]
on 1 Oct 2009 at 1:52
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
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
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
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
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.