MantisBT - VTK
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012718VTK(No Category)public2011-11-10 11:182012-01-09 12:16
Reportertd123 
Assigned ToDavid Partyka 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
ProjectTBD
Typeincorrect functionality
Summary0012718: Paraview 3.12.0 fails to build against protobuf 2.4.1
DescriptionIf I build without protobuf installed, it passes configuration, but then later I get the error:
[ 84%] Generating vtkPVMessage.pb.h, vtkPVMessage.pb.cc
/build/src/ParaView-3.12.0/build/bin/protoc: error while loading shared libraries: libprotoc.so: cannot open shared object file: No such file or directory

which causes:
fatal error: vtkPVMessage.pb.h: No such file or directory

If I install protobuf 2.4.1 on my system and try to compile, I get the following error:
[ 84%] Building CXX object ParaViewCore/ServerImplementation/CMakeFiles/vtkPVServerImplementation.dir/vtkPVSessionBase.cxx.o
In file included from /build/src/ParaView-3.12.0/ParaViewCore/ServerImplementation/vtkSMMessage.h:30:0,
                 from /build/src/ParaView-3.12.0/ParaViewCore/ServerImplementation/vtkPVSessionBase.cxx:22:
/build/src/ParaView-3.12.0/build/ParaViewCore/ServerImplementation/vtkPVMessage.pb.h:12:2: error: #error This file was generated by a newer version of protoc which is incompatible with your Protocol Buffer headers. Please update your headers.

It seems that the configure script should be configured to add support for detecting if protobuf is installed and maybe regenerating the headers if a newer version is installed. I'm building this on archlinux.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filestxt output.txt (1,249,087) 2011-11-10 11:18
https://www.vtk.org/Bug/file/9067/output.txt
txt output-with-protobuf.txt (1,265,408) 2011-11-10 11:19
https://www.vtk.org/Bug/file/9068/output-with-protobuf.txt
Issue History
Date ModifiedUsernameFieldChange
2011-11-10 11:18td123New Issue
2011-11-10 11:18td123File Added: output.txt
2011-11-10 11:19td123File Added: output-with-protobuf.txt
2011-11-10 11:20td123Note Added: 0027676
2011-11-23 03:13Paul MelisNote Added: 0027729
2011-12-01 00:12Paul MelisNote Added: 0027749
2012-01-07 10:46td123Note Added: 0027916
2012-01-07 11:20td123Note Added: 0027917
2012-01-07 12:55td123Note Added: 0027918
2012-01-09 10:04David PartykaNote Added: 0027923
2012-01-09 11:18td123Note Added: 0027924
2012-01-09 12:14David PartykaAssigned To => David Partyka
2012-01-09 12:14David PartykaStatusbacklog => todo
2012-01-09 12:14David PartykaResolutionopen => fixed
2012-01-09 12:15David PartykaStatustodo => active development
2012-01-09 12:15David PartykaStatusactive development => gatekeeper review
2012-01-09 12:16David PartykaStatusgatekeeper review => customer review
2012-01-09 12:16David PartykaNote Added: 0027925
2012-01-09 12:16David PartykaStatuscustomer review => closed

Notes
(0027676)
td123   
2011-11-10 11:20   
I have attached:
output.txt which is the full build log for building paraview 3.12.0 without protobuf installed.
output-with-protobuf.txt which is the full build log for building with protobuf installed.
(0027729)
Paul Melis   
2011-11-23 03:13   
Same here on a Gentoo Linux system, which has protobuf 2.4.0 installed
(0027749)
Paul Melis   
2011-12-01 00:12   
On my system it looks like what actually is happening is:

1. The system-installed protobuf compiler is used to generate vtkPVMessage.pb.h & vtkPVMessage.pb.cxx in the build dir. System-installed version is protobuf 2.4.0
2. During compilation the in-source protobuf headers are used, from ParaView-3.12.0/Utilities/protobuf/src. This is an older version, protobuf 2.3.0, causing the generated vtkPVMessage.pb.h to give the #error above.

Strangely enough, in <build-dir>/bin there is a protoc executable (from 2.3.0). And I see the following after removing the protobuf-generated files and re-running make:

[ 82%] Generating vtkPVMessage.pb.h, vtkPVMessage.pb.cc
cd /home/melis/c/paraview-3.12.0-build/ParaViewCore/ServerImplementation && /usr/bin/cmake -DOutDir=. -P /home/melis/c/paraview-3.12.0-build/ParaViewCore/ServerImplementation/ExecuteProtoC.cmake

That cmake file, /home/melis/c/paraview-3.12.0-build/ParaViewCore/ServerImplementation/ExecuteProtoC.cmake, contains:

execute_process(
  COMMAND "/home/melis/c/paraview-3.12.0-build/bin/protoc" "--cpp_out=dllexport_decl=VTK_PROTOBUF_EXPORT:/home/melis/c/paraview-3.12.0-build/ParaViewCore/ServerImplementation" --proto_path "/home/melis/c/ParaView-3.12.0/ParaViewCore/ServerImplementation/Resources" "/home/melis/c/ParaView-3.12.0/ParaViewCore/ServerImplementation/Resources/vtkPVMessage.proto"
  WORKING_DIRECTORY "/home/melis/c/paraview-3.12.0-build/ParaViewCore/ServerImplementation"
)

Which is the correct command, because if I execute it by hand I get 2.3.0 generated files and the PV build succeeds... I have no idea why it doesn't get executed properly when it is called from the build.
(0027916)
td123   
2012-01-07 10:46   
I decided to take another look yesterday evening, and I think I came up with what is going on.

When paraview's own protoc runs without a system protobufs available, it can not find libprotoc.so even though it is in the same directory as paraview's libprotoc.so.

When paraview's own protoc runs with a system protobufs available, it still can not find the libprotoc.so in the current directory (paraview's libprotoc.so) but it instead uses the system's libprotoc.so.

This is why the command to use paraview's protoc looks right, but produces an incorrect result.

The way I have currently temporarily fixed it is I removed -DCMAKE_SKIP_RPATH:BOOL=YES from my cmake arguments. This works when I build it without a system-wide protobufs lib installed. Haven't tested with one installed.

Also, it would be nice to consider adding an option to use the system's protobufs. I don't know how backwards incompatible protobufs are.
(0027917)
td123   
2012-01-07 11:20   
Oh, another thing I found out is that one of the flags I use:
-DBUILD_SHARED_LIBS:BOOL=ON
has a description of: "BUILD_SHARED_LIBS: Build shared protobuf library"

This might be another potential problem area. If it builds a static library for protobufs, then this might also be a fix for this problem. This flag probably deserves a more descriptive name like "BUILD_SHARED_PROTOBUF_LIBS" again, I haven't tested this because building paraview takes a while for me.
(0027918)
td123   
2012-01-07 12:55   
I have built with -DCMAKE_SKIP_RPATH:BOOL=YES and -DBUILD_SHARED_LIBS:BOOL=OFF which resulted with the same "error while loading shared libraries: libprotoc.so" message. It seems that for now, it has to be built with the default -DCMAKE_SKIP_RPATH:BOOL=FALSE until this bug gets fixed.
(0027923)
David Partyka   
2012-01-09 10:04   
This is a ParaView bug. Please submit ParaView bugs into the ParaView bug tracker. (Change Project to ParaView at the top of the page and re-report the issue). I don't have the ability to simply move this bug to that tracker or I would do that instead.
(0027924)
td123   
2012-01-09 11:18   
ok, sorry, I just didn't know you could switch the project type on the top right.

reposted on http://paraview.org/Bug/view.php?id=12852 [^]

I will let you close it because I don't know if there is any procedure you do for these types of bugs.

Thanks.
(0027925)
David Partyka   
2012-01-09 12:16   
Cool thank you, closing this.