MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015128CMakeModulespublic2014-09-03 18:292015-04-06 09:07
ReporterOrion E. Poplawski 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product VersionCMake 3.0.1 
Target VersionFixed in Version 
Summary0015128: FindProtobuf issues
DescriptionFor the Fedora package build of ParaView, we need to use system libraries. I have been patching ParaView to use the system protobuf library (see http://www.paraview.org/Bug/view.php?id=13656 [^]) for a while now and am updating to 4.2RC1. With that I am now seeing issues with the interaction with the cmake FindProtobuf module, due to the fact that it uses the optimize/debug list convention and add -lpthread to PROTOBUF_LIBRARIES.

Part of the issue is the way it looks for a debug library:

   find_library(${name}_LIBRARY
       NAMES ${filename}
       PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/Release)
   mark_as_advanced(${name}_LIBRARY)

   find_library(${name}_LIBRARY_DEBUG
       NAMES ${filename}
       PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/Debug)
   mark_as_advanced(${name}_LIBRARY_DEBUG)

On Linux/Unix this generally finds the same library in the same path. Changing to:

   find_library(${name}_LIBRARY_DEBUG
       NAMES ${filename}
       PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/Debug NO_DEFAULT_PATH)
   mark_as_advanced(${name}_LIBRARY_DEBUG)

helps with that.

I'm not sure what to do with the addition of -lphtreads. Simply removing it may be the way to go. The paraview protobuf cmake configuration seems to add it to protobuf_LIB_DEPS.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespatch cmake-FindProtobuf.patch (615) 2014-09-03 18:30
https://public.kitware.com/Bug/file/5241/cmake-FindProtobuf.patch
Issue History
Date ModifiedUsernameFieldChange
2014-09-03 18:29Orion E. PoplawskiNew Issue
2014-09-03 18:30Orion E. PoplawskiFile Added: cmake-FindProtobuf.patch
2014-09-04 10:39Brad KingAssigned To => Ben Boeckel
2014-09-04 10:39Brad KingStatusnew => assigned
2014-09-04 10:40Brad KingTarget Version => CMake 3.1
2014-09-04 12:24mwoehlkeNote Added: 0036731
2014-09-04 12:33Orion PoplawskiNote Added: 0036732
2014-09-04 13:00mwoehlkeNote Added: 0036733
2014-09-05 11:33Orion E. PoplawskiNote Added: 0036734
2014-10-03 09:32Brad KingNote Added: 0036897
2014-10-03 09:32Brad KingAssigned ToBen Boeckel =>
2014-10-03 09:32Brad KingStatusassigned => resolved
2014-10-03 09:32Brad KingResolutionopen => no change required
2014-10-03 09:32Brad KingTarget VersionCMake 3.1 =>
2015-04-06 09:07Robert MaynardNote Added: 0038414
2015-04-06 09:07Robert MaynardStatusresolved => closed

Notes
(0036731)
mwoehlke   
2014-09-04 12:24   
I don't think removing pthreads is the correct answer. As seen in http://www.paraview.org/Bug/view.php?id=13656 [^] (and the commit which added it in the first place), using protobuf brings a dependency on pthreads (on Linux, anyway). Users should not need to be aware of this; linking to PROTOBUF_LIBRARIES should be sufficient.

Giving the actual library path rather than '-lpthreads' might be a possibility; I don't know the history if there is any reason why that's not being done, or if it would fix this problem.

(Also, given CMake's policies, I don't think it *can* be removed, since you risk breaking the build of every project using FindProtobuf.cmake as shipped by CMake.)
(0036732)
Orion Poplawski   
2014-09-04 12:33   
These are the errors I get when the system FindProtobuf add -lpthread to PROTOBUF_LIBRARIES:

CMake Error at CommandLineExecutables/CMakeLists.txt:71 (get_property):
  get_property could not find TARGET -lpthread. Perhaps it has not yet been
  created.


CMake Error at CommandLineExecutables/CMakeLists.txt:76 (get_property):
  get_property could not find TARGET -lpthread. Perhaps it has not yet been
  created.

Not sure if this is more of an issue with the ParaView cmake code making assumptions about various libraries, or something that should be fixed in cmake's FindProtobuf.
(0036733)
mwoehlke   
2014-09-04 13:00   
Ah, yes. Paraview (and to a lesser extent, VTK) does some really gnarly stuff with CMake; ergo, I'd say "the former". I remember now I ran into the same issue.

You could try this patch:

diff --git a/CommandLineExecutables/CMakeLists.txt b/CommandLineExecutables/CMakeLists.txt
index 33e35c3..cf4da06 100644
--- a/CommandLineExecutables/CMakeLists.txt
+++ b/CommandLineExecutables/CMakeLists.txt
@@ -64,7 +64,12 @@ foreach (vtk_module IN LISTS VTK_MODULES_ENABLED extra_modules)
     file(APPEND "${CMAKE_CURRENT_BINARY_DIR}/vtkModuleDependencies.h"
 "const char* ${vtk_module}Libraries[] = { ")
     foreach (vtk_module_library IN LISTS "${vtk_module}_LIBRARIES")
- if (IS_ABSOLUTE "${vtk_module_library}")
+ if (vtk_module_library STREQUAL "optimized" OR vtk_module_library STREQUAL "debug")
+ unset(vtk_module_library_name)
+ elseif (vtk_module_library MATCHES "^-l")
+ string(SUBSTRING ${vtk_module_library} 2 -1 vtk_module_library)
+ find_library(vtk_module_library_name ${vtk_module_library})
+ elseif (IS_ABSOLUTE "${vtk_module_library}")
         set(vtk_module_library_name "${vtk_module_library}")
       elseif (vtk_module_library)
         set(type)
(0036734)
Orion E. Poplawski   
2014-09-05 11:33   
Yeah, that seems to help, thanks.
(0036897)
Brad King   
2014-10-03 09:32   
AFAICT the patch in 0015128:0036733 for ParaView resolves this. The patch to CMake originally attached here looks like a hack to prevent the debug library from being found. The real issue is the way ParaView was dealing with the list of libraries, and that has now been resolved.
(0038414)
Robert Maynard   
2015-04-06 09:07   
Closing resolved issues that have not been updated in more than 4 months.