-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CMake support for glog #4
Comments
I've added CMake support to glog: https://github.com/sergiud/glog. Tested on Windows using VC 8.0-14.0 CTP 6 and cygwin gcc 4.9.2, and on Arch Linux using gcc 4.9.2 and clang 3.6. Usage in a CMake project: cmake_minimum_required (VERSION 2.8.11)
project (myproject)
find_package (glog 0.3.4)
add_executable (myproject myproject.cpp)
target_link_libraries (myproject glog) |
Hi thanks for your work ! I will test it asap. |
There are minor things left to be done. Once I'm done, I'll create a pull request. |
When adding cmake support it would be nice to have also mingw support on windows. |
MinGW and CMake support are pretty much unrelated issues. MinGW is simply missing functions that are required to compile glog. |
Thank you for your help. I was able to compile glog with mingw, but I had to use msys to run the configure script, and there were some linker problems with the test. Also there are some problems with pthreads, because glog defines its own pthreads. I had to use mingw without pthread support. But I was able to use the library in my project that I compiled with MinGW and the logging could be used correctly. MinGW does not support symbolic links, but glog can be used without this functionality. I just thought that during the cmake process one could check for mingw compiler and set the correct macros. Currently I am testing your cmake fork and it also seems that somehow the MSVC Project can not include the gflags headers correctly. |
What MinGW version are you using? Maybe I can take a look. Would you also post the CMake/compiler output regarding the gflags problem? Thanks. |
I am using mingw-w64: i686-4.9.2-win32-sjlj-rt_v3-rev1 from the mingw-w64 project. #include <stdlib.h>
...
# if defined(_WIN32) && !defined(__CYGWIN__) && !defined(__MINGW32__)
# define GOOGLE_GLOG_DLL_DECL __declspec(dllimport)
# else
# define GOOGLE_GLOG_DLL_DECL
# endif The problem with gflags is, that the headers are not found.
From the CmakeCache.txt
Additionally you could add Cache variable in cmake to disable gflags. Thank you |
My MinGW installation is missing the |
As a side note, you have to use the |
Thank you. Compiling without gflags with MSVS works now.
in logging.cc line 105, 107, 134, 1034, 175, 140, 142, 172, 138, 128, 166, 168 and
'int64' and 'uint32' in several lines in logging_unittest.cc mingw with posix threads is not compiling, I will try mingw with win32 threads later. |
Thanks for letting me know. The gflags issues should be fixed now. |
using mingw with win32 threads:
using mingw with posix threads:
|
I see. Adding MinGW support basically requires some code refactoring, which I can't really help with. |
Thank you very much for your help. In the release 0.3.4, the developers added the feature
I hope they will continue adding mingw-w64 on windows with cmake. |
sergiud, there's a bug in your CMake build somewhere, on Windows 7 with Visual Studio 2013 Community Edition at least. It doesn't copy the glog\log_severity.h file. I haven't found the cause yet. I'm building in build\serguid_glog. My build\sergiud_glog\glog directory doesn't have the file, although all the other *.h files are present. build\sergiud_glog\install_manifest.txt does not list the file, but the other *.h files are listed. As I have not found an explicit list of these files for installation, I am guessing you used some kind of automated routine to grab all the needed files, and had an endpoint error iterating through them. I would have filed this as an issue in your github repository, but you don't seem to have Issues enabled. Anyways count me as someone who'd like to see an official CMake build for glog. I've found 3 different ones including sergiud's. I'm currently dealing with 2 projects that consume gflags and glog, that aren't working well with gflags detection or glog building in Visual Studio 2013. The .sln files that glog proper provides, are only 32-bit when imported to Visual Studio 2013. 7 project upgrade errors are given, which might be worrisome. |
@bvanevery, good catch. I failed to include |
sergiud, are you going to fix that in your repo? Or at least enable Issues reporting in your repo, so that it's not forgotten? |
@bvanevery I've enabled issues in my repository. |
@sergiud Hi, I am glad that you make google-glog support CMake, however, I write a
My OS is Arch Linux, and I execute
Any ides? Thank you! |
Glog 0.3.5 which includes CMake support has not been released yet. You'll have to compile Glog from source. |
@sergiud So it is! Thank you! |
@sergiud Hi, I write the PKBGUILD to comiple Glog from source, however, I find it does not compile See my compile output and PKGBUILD: https://gist.github.com/acgtyrant/ae5794c37cef79c8464c |
Summary: Issue google#80 points out several places in glog where TSAN discovers false positives. One of these places is in the `LOG_EVERY_N` macros. These macros are implemented by maintaining a static unprotected integer counter, and TSAN will report data races on these counters. Here is a minimum example to reproduce the data race: ``` void logging() { for (int i = 0; i < 300; ++i) { LOG_EVERY_N(INFO, 2) << "foo"; } } int main() { auto t1 = std::thread(logging); auto t2 = std::thread(logging); t1.join(); t2.join(); return 0; } ``` And here is the TSAN report: ``` WARNING: ThreadSanitizer: data race (pid=776850) Write of size 4 at 0x558de483f684 by thread T2: #0 logging() google#1 void std::_Bind_simple<void (*())()>::_M_invoke<>(std::_Index_tuple<>) google#2 std::_Bind_simple<void (*())()>::operator()() google#3 std::thread::_Impl<std::_Bind_simple<void (*())()> >::_M_run() google#4 execute_native_thread_routine Previous write of size 4 at 0x558de483f684 by thread T1: #0 logging() google#1 void std::_Bind_simple<void (*())()>::_M_invoke<>(std::_Index_tuple<>) google#2 std::_Bind_simple<void (*())()>::operator()() google#3 std::thread::_Impl<std::_Bind_simple<void (*())()> >::_M_run() google#4 execute_native_thread_routine Location is global '<null>' at 0x000000000000 (main+0x00000011c684) Thread T2 (tid=776857, running) created by main thread at: #0 pthread_create google#1 __gthread_create google#2 std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>, void (*)()) google#3 main Thread T1 (tid=776856, running) created by main thread at: #0 pthread_create google#1 __gthread_create google#2 std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>, void (*)()) google#3 main SUMMARY: ThreadSanitizer: data race in logging() ``` To avoid noisy TSAN reports and also avoid adding a performance hit, this change will mark these counters as benign races so that TSAN will not report them. This change will only have an effect if we are compiling with TSAN; there are no changes if we are not building with TSAN. With this change, the above example no longer reports a data race when built and run with TSAN.
Just for the sake of completeness. I recently had some issues with how the glog CMake implementation works. It is not glog related I guess it is how CMake's This example form ifm3d will fail compilation at least under Windows with Visual Studio 2017 file(GLOB IFM3D_CAMERA_SOURCES *.cpp)
add_library(ifm3d_camera OBJECT ${IFM3D_CAMERA_SOURCES})
set_property(TARGET ifm3d_camera PROPERTY POSITION_INDEPENDENT_CODE 1)
add_library(ifm3d_camera_shared SHARED $<TARGET_OBJECTS:ifm3d_camera>)
target_link_libraries(
ifm3d_camera_shared
glog::glog
${LIB_xmlrpcxx}
${LIB_xmlrpc_clientxx}
) The fix is pretty easy but maybe this save someone some time find_package(Boost REQUIRED COMPONENTS system date_time regex)
find_package(glog REQUIRED CONFIG NAMES google-glog glog)
if (NOT TARGET glog::glog)
find_library(LIB_glog NAMES glog)
else()
set(LIB_glog glog::glog)
endif (NOT TARGET glog::glog)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
file(GLOB IFM3D_FG_SOURCES *.cpp)
add_library(
ifm3d_framegrabber_shared SHARED ${IFM3D_FG_SOURCES}
)
set_property(TARGET ifm3d_framegrabber_shared PROPERTY POSITION_INDEPENDENT_CODE 1)
target_link_libraries(
ifm3d_framegrabber_shared
ifm3d_camera_shared
${LIB_glog}
${Boost_LIBRARIES}
${CMAKE_THREAD_LIBS_INIT}
) |
You have two code paths there. The first one (which calls I don't see how the problem is related to CMake's config mode or object-libraries. Why do you need to locate glog using |
@sergiud the
|
As per CMake documentation object libraries only compile the sources. You need to add another library which uses the objects and then you can link to the imported |
Thanks for the hint with the extra library and I highly appreciate your CMake support for glog which saved me a lot of time. I tried to explain in the comments above I do not consider this a bug in Glogs CMake implementation nor in the CMake itself. It was just something which took me quite some time to figure out. And I tried to document it somehow so maybe I can save someone some time. |
i want to know how you solve this problem. i also met this case! |
@majiqiang It looks like Arch uses |
@graugans What should I do specifically? I first installed various dependencies, such as glog, egien3, and so on. Then I git clone handeye-calib-camodocal to my workspace ~/catkin_ws/src, and catkin_make. but I got the errors:
|
@majiqiang you can try to get in touch with the Arch guys so they fix it. or you can build glog from source. |
@graugans you mean this? |
This will not help. This is exactly how the Arch Maintainer builds. You have to use CMake. https://github.com/google/glog/blob/master/cmake/INSTALL.md |
Whenever I build on windows I get a warning fLB::FLAGS_logtostderr': inconsistent dll linkage Anyone point me in the right direction? |
Add CMake support. closes google#4
When I execute the cmake, it says the add_library cannot create imported target "glog::glog" because another -- Found Glog -- Found required Ceres dependency: glog |
With the information you provided it is hard to tell what is going on. However, if had to guess I'd say that you are using broken/outdated distribution that does not provide a CMake glog package configuration or the project that you are trying to compile is mixing different glog versions. I suggest opening a separate issue with detailed information on how to reproduce the error. |
I met the same problem. Modify line 349 of FindGlog.cmake to:
It works for me. |
omg @dawnzyt thank you, glomap is about to be built ;) |
Hi
would it be possible to add cmake support for Glog ? Gflags already support cmake, it would be consistent to have glog supporting it also.
It seems that there have been attempts to do that in the past.
Thanks you very much in advance
The text was updated successfully, but these errors were encountered: