gflags on windows with visual studio 2013: ParseCommandLineFlags has no effect

[andreas...@gmail.com]

Hi folks,

I use Microsoft Visual Studio 2013 under Windows 7 64Bit and gflags 2.0. 

I opened the visual studio project that came with the zip-distribution of gflags, changed to x84 like it is described in the windows readme file.

Then I compiled the project and copied the .dll over to my project which I want to use gflags with. I added src/windows to the include directories and added libgflags.lib to the linker dependencies.

In my main.cpp I have "#include <gflags\gflags.h>" in the head section and two DEFINE_bool statements. In the main-method, I added:

google::SetVersionString("0.3");
google::ParseCommandLineFlags(&argc, &argv, false);

I added a check to the boolean flag with "if (FLAG_myflag) { ... }" to check if the command-line args are successfully processed.

The project compiles without errors, I got some warnings regarding google::CommandLineFlagInfo::* but nothing fancy. However, when I call the binary with myprog.exe --longhelp --version --myflag --help it has no effect: The cout statement I added after the ParseCommandLineFlags statement does its output, but no help screen comes up and my flag is not set (it is initialized with false and it stays false despite of the "--myflag" parameter).

Can someone please tell me how I can dig into that any further?

Thank you!

Andreas

[Andreas Schuh]

Hi Andreas,

I am just wondering if the reported "needs to have dll-interface to be used by clients" warnings could be related ? Have you tried to link statically instead ?

https://code.google.com/p/gflags/issues/detail?id=73

Andreas

[andreas...@gmail.com]

Hi equally named user,

I tried to use static linking. In fact I initially wanted to achieve static linking but I wasn't able to get it working:

I can switch the configuration type to static library (.lib) in the project options for libgflags. It compiles successfully with warnings but without errors. I get a libgflags.lib but my project using gflags doesn't build anymore: I get unsatisfied link errors for every gflags-call in my source file.

In the file README_windows.txt is a description for static linking. It says I should add the parameters "/D GFLAGS_DLL_DECL= /D GFLAGS_DLL_DECLARE_FLAG= /D GFLAGS_DLL_DEFINE_FLAG=" for every gflags .cc file. I'm not exactly sure how to do this: I pasted it into the text area "additional options" under c/c++ / commandline in the project options and did a project rebuild after that. Maybe this is just wrong?

I switched to dll linking just because it was the only way for me to get around these unresolved link errors.

Do you also use visual studio and have static linking working? If so, what have you changed in the project options?

I can provide any build logs if this helps.

Thank you!

Andreas

[Andreas Schuh]

On Thursday, March 13, 2014 2:23:21 PM UTC, andreas...@gmail.com wrote:

Hi equally named user,

I tried to use static linking. In fact I initially wanted to achieve static linking but I wasn't able to get it working:

I can switch the configuration type to static library (.lib) in the project options for libgflags. It compiles successfully with warnings but without errors. I get a libgflags.lib but my project using gflags doesn't build anymore: I get unsatisfied link errors for every gflags-call in my source file.

In the file README_windows.txt is a description for static linking. It says I should add the parameters "/D GFLAGS_DLL_DECL= /D GFLAGS_DLL_DECLARE_FLAG= /D GFLAGS_DLL_DEFINE_FLAG=" for every gflags .cc file. I'm not exactly sure how to do this: I pasted it into the text area "additional options" under c/c++ / commandline in the project options and did a project rebuild after that. Maybe this is just wrong?

Many years have passed since I last used VS so I couldn't tell you from the top of my head. But my conclusion is rather that all this should not be required by a user of the gflags library. It should be rather taken care of by the build configuration process (CMake). Maybe the CMake branch of the library helps, if not I would like to see what modifications are needed to make it work seamless. I am not going to further maintain the autotools build configuration of the gflags package.

 

I switched to dll linking just because it was the only way for me to get around these unresolved link errors.

Both should work of course, we just need to figure what changes are necessary to make this happen. I assume static linkage would be the higher priority given that most gflags users presumable prefer to link in such utility library statically to not depend on any additional DLL.

[Andreas Schuh]

Hi Andreas,

please try again with the Git cmake-migration branch. After fixing the build configuration and export declarations, I was able to build both static and shared libraries successfully.

I will fix the remaining DLL export warnings next.

Andreas

[Andreas Piening]

Hi Andreas,

thank you very much. I’ve configured the branch without BUILD_SHARED_LIBS in cmake and compiled it with VS2013. I’ve created a super simple test project which defines a single boolean flag and outputs whether it has been set or not.

It builds just fine (linked statically against gflags) but the binary does not respond to -help, —help, /help, -longhelp, —lomghelp or /longhelp and not to my defined flag as well. It just ignores all parameters I gave it on the command line.

Maybe I did something very stupidly wrong I can’t think of, but I don’t know where to look after the problem.

If I can provide any additional information please feel free to ask.

Thank you again,

Andreas

[Andreas Schuh]

On Sunday, March 16, 2014 10:39:42 PM UTC, Andreas Piening wrote:

Hi Andreas,

thank you very much. I’ve configured the branch without BUILD_SHARED_LIBS in cmake and compiled it with VS2013. I’ve created a super simple test project which defines a single boolean flag and outputs whether it has been set or not.

Good. I think the dynamic linkage to the gflags library is yet not possible on Windows because not all needed symbols are actually exported. I will look into this tomorrow when I have access to my Windows machine again.

It builds just fine (linked statically against gflags) but the binary does not respond to -help, —help, /help, -longhelp, —lomghelp or /longhelp and not to my defined flag as well. It just ignores all parameters I gave it on the command line.

Thus far I have only tested it using the unit tests included in the gflags package which worked fine (using VS2010). I still need to test it with a separate project that uses "find_package(gflags)" and a link dependency on the imported "gflags" CMake build target.

[Andreas Schuh]

Hi Andreas,

the CMake migration for Windows should now be completed. I was able to build both static and shared libraries with VS2010, Cygwin GCC, and MinGW GCC. The unit tests also passed which link in these libraries. Only on Cygwin there is yet an issue reading flags from a file (--flagfile option).

Please try again with the latest cmake-migration changes.

Andreas