View Issue Details [ Jump to Notes ] [ Print ]
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.
TagsNo tags attached.
Attached Filespatch file icon cmake-FindProtobuf.patch [^] (615 bytes) 2014-09-03 18:30 [Show Content]

 Relationships

  Notes
(0036731)
mwoehlke (developer)
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 (reporter)
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 (developer)
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 (reporter)
2014-09-05 11:33

 Yeah, that seems to help, thanks.
(0036897)
Brad King (manager)
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 (manager)
2015-04-06 09:07

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2014-09-03 18:29 Orion E. Poplawski New Issue
2014-09-03 18:30 Orion E. Poplawski File Added: cmake-FindProtobuf.patch
2014-09-04 10:39 Brad King Assigned To => Ben Boeckel
2014-09-04 10:39 Brad King Status new => assigned
2014-09-04 10:40 Brad King Target Version => CMake 3.1
2014-09-04 12:24 mwoehlke Note Added: 0036731
2014-09-04 12:33 Orion Poplawski Note Added: 0036732
2014-09-04 13:00 mwoehlke Note Added: 0036733
2014-09-05 11:33 Orion E. Poplawski Note Added: 0036734
2014-10-03 09:32 Brad King Note Added: 0036897
2014-10-03 09:32 Brad King Assigned To Ben Boeckel =>
2014-10-03 09:32 Brad King Status assigned => resolved
2014-10-03 09:32 Brad King Resolution open => no change required
2014-10-03 09:32 Brad King Target Version CMake 3.1 =>
2015-04-06 09:07 Robert Maynard Note Added: 0038414
2015-04-06 09:07 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team