search

sibojia / google-glog

Automatically exported from code.google.com/p/google-glog
Other
0 stars 0 forks source link

Support configuring glog to use a local copy of gflags #106

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. #include <glog/logging.h> in your C++ program
2. #include <gflags/gflags.h> as well.
3. Use the flag FLAGS_logtostderr that was declared in glog/logging.h.
4. Compile and link your program, including a link to the gflags library
5. You'll get a link error ::flb::FLAGS_linktostderr
6. Now remove the references to gflags and rebuild.
7. No link error!

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

See above.

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

glog 0.3.1;  Mac OS/X 10.6.8

This problem seems to be new to glog 0.3.1, which I just installed.  I need 
this version because DFATAL doesn't work on Mac OS/X and 0.3.0.

Please provide any additional information below.

This is a development system and as such I'm building and installing my target 
libraries into a specific build directory, not the system library directories.  
This has caused me some issues with other packages in the past that are e.g. 
expecting dependencies in the system library areas.

I attempted to fix this issue in glog by turning off and on by hand the 
recognition of the gflags library in the Makefile built by the config process - 
no apparent change.

Original issue reported on code.google.com by tom.ritc...@gmail.com on 25 Nov 2011 at 5:53

GoogleCodeExporter commented 9 years ago 
I have glog and gflags in an open source project, and I had to make some 
modifications to have glog use my local copy of gflags:

http://code.google.com/p/ymer/source/detail?r=98

The relevant changes are to configure.ac and src/demangle_unittest.sh.

I notice now that I made a mistake in one of the comments, which results in a 
spurious diff for src/config.h.in.  In any case, the changes to configure and 
src/config.h.in are generated from the changes to configure.ac, so they are not 
interesting.

It would be nice if there was a way to configure glog to do this without 
changing configure.ac.  I would be curious to know if my modifications work for 
you?

Original comment by hlsyou...@gmail.com on 28 Dec 2011 at 4:16

GoogleCodeExporter commented 9 years ago 
Oh, dear.  It turned out that when the dust settled, I had no need for gflags, 
and it got ripped out months ago.  So there's no easy way for me to check if 
your patch does the trick on my project.

Original comment by tom.ritc...@gmail.com on 28 Dec 2011 at 5:16

GoogleCodeExporter commented 9 years ago 
OK, I'll hijack this bug then, since I still have this issue and dislike having 
a patched version of glog in my project.  Please object if you think your issue 
was different from mine.

Description of my problem:

If you have local copies of glog and gflags in your project, you need to make 
glog use your local copy of gflags instead of an installed version.  Otherwise 
you will get linker errors due to multiple definitions of the same symbol.  
Currently this requires a change to configure.ac (and also one of the tests).  
It would be nice if glog could be configured to use a local copy of gflags 
simply by passing some flag to the configure script.

Original comment by hlsyou...@gmail.com on 28 Dec 2011 at 6:34

GoogleCodeExporter commented 9 years ago

Original comment by hlsyou...@gmail.com on 28 Dec 2011 at 6:35

GoogleCodeExporter commented 9 years ago 
Good for you!  (I'm not a Googler any more so I can't really take ownership of 
bugs here anyway... or can I?)

I'm unlikely to change my project (in advanced beta right now) to use gflags 
again for at least a few months - BUT if you need someone to test whether it 
works on Mac and have a specific test project I could bring over and build, 
that I could do.

Original comment by tom.ritc...@gmail.com on 28 Dec 2011 at 6:41