[Paraview-developers] Problems with protobuf when loading self-compiled plugin on OS X

Michael Schlottke m.schlottke at aia.rwth-aachen.de
Mon Jun 17 05:48:35 EDT 2013 

Hi Utkarsh,

Thank you for the very specific help. That indeed did the trick. My only question remaining is, if this can be done at the cmake level. But I guess this would entail a lot of fiddling with platform-specific cmake code.

Anyhow, for those who are running into the same problems, I've attached a little script that takes the path to the paraview build dir and one or more .dylib files and fixes the paths in the plugins (use at your own risk, get help by running "pvmac_fix_libpath -h").

Regards,

Michael



On Jun 14, 2013, at 18:44 , Utkarsh Ayachit wrote:

> Michael,
> 
> Any plugin that you build externally need to be "fixed" so it they doesn't refer to the libraries it was built with. 
> 
> Try the following:
> 
> > otool -L <plugin>.dylib
> 
> What does the output show?
> It will show paths to the libraries that the plugin was built against.
> 
> Now do the same for a plugin under the /Applications/ParaVeiw.app/ e.g.
> > otool -L /Applications/ParaView.app/Contents/Plugins/libEyeDomeLightingView.dylib
> 
> Look at the result. This library refers to dependencies using @executable_path/.../ unlike your plugin (I assume).
> 
> You need to "fixup" your plugin dylib to refer to correct libraries. That can be done using install_name for each of the incorrectly referenced libraries.
> 
> > install_name_tool -change <old name> <new name> <plugin>.dylib
> 
> You can generally write a python or shell script to do the same.
> 
> e.g. to get a list of libraries that the plugin refers to using non-relative paths, you can do the following:
> 
> > otool -l  <YOURPLUGIN>.dylib | grep " name" | sort | uniq | sed "s/name\ //" | grep -v "@" | sed "s/ (offset.*)//"
> 
> Any of those names that refer to your ParaView build directory need to be fixed. So you can extend the query to remove any paths not in your build directory ....and so on.
> 
> Utkarsh
> 
> 
> On Fri, Jun 14, 2013 at 8:19 AM, Michael Schlottke <m.schlottke at aia.rwth-aachen.de> wrote:
> Hi everyone,
> 
> I tried the new RC3 and I still get the same errors when trying to load a self-compiled plugin from the paraview.app application:
> 
> ##############################################
> objc[59843]: Class vtkCocoaTimer is implemented in both /Applications/ParaView 4.0.0-RC3.app/Contents/MacOS/../Libraries/libvtkRenderingOpenGL-pv4.0.1.dylib and /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC3/lib/libvtkRenderingOpenGL-pv4.0.1.dylib. One of the two will be used. Which one is undefined.
> objc[59843]: Class vtkCocoaServer is implemented in both /Applications/ParaView 4.0.0-RC3.app/Contents/MacOS/../Libraries/libvtkRenderingOpenGL-pv4.0.1.dylib and /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC3/lib/libvtkRenderingOpenGL-pv4.0.1.dylib. One of the two will be used. Which one is undefined.
> objc[59843]: Class vtkCocoaFullScreenWindow is implemented in both /Applications/ParaView 4.0.0-RC3.app/Contents/MacOS/../Libraries/libvtkRenderingOpenGL-pv4.0.1.dylib and /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC3/lib/libvtkRenderingOpenGL-pv4.0.1.dylib. One of the two will be used. Which one is undefined.
> objc[59843]: Class vtkCocoaGLView is implemented in both /Applications/ParaView 4.0.0-RC3.app/Contents/MacOS/../Libraries/libvtkRenderingOpenGL-pv4.0.1.dylib and /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC3/lib/libvtkRenderingOpenGL-pv4.0.1.dylib. One of the two will be used. Which one is undefined.
> libprotobuf ERROR /Users/mic/.BuiltFromSource/.sources/ParaView-4.0.0-RC3-source/ThirdParty/protobuf/vtkprotobuf/src/google/protobuf/descriptor_database.cc:109] Symbol name "google.protobuf.NamePart" conflicts with the existing symbol "google.protobuf.NamePart".
> libprotobuf FATAL /Users/mic/.BuiltFromSource/.sources/ParaView-4.0.0-RC3-source/ThirdParty/protobuf/vtkprotobuf/src/google/protobuf/descriptor.cc:860] CHECK failed: generated_database_->Add(encoded_file_descriptor, size):
> Abort trap: 6
> ##############################################
> 
> It seems to be that the problem is related to the fact that I compile the plugin using ParaView_DIR= /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC3. However, the bundled paraview.app (in my case: /Applications/ParaView 4.0.0-RC3.app) brings its own libraries (which generally smart, I guess, since that way the builddir can be deleted after doing 'make install'). Unfortunately, I have not been able to build my plugins against the /Applications/ParaView 4.0.0-RC3.app (cmake doesn't find ParaView there).
> 
> I see three possible ways to solve this problem: 
> 
> 1) Modify the paraview.app bundle so that it is recognized as a valid paraview dir (and probably copy some more files there that are needed for the plugins)
> 2) Modify the paraview.app bundle so that it does NOT have it's own library files anymore, but resorts to using the ones in the builder
> 3) Modify the plugin loading mechanism so that it does not reload libraries that were already loaded in ParaView
> 
> However, here I run out of ideas and knowledge of how to achieve this. Does anyone have a hot fix or even a permanent solution to this issue?
> 
> Regards,
> 
> Michael
> 
> On May 30, 2013, at 17:27 , Utkarsh Ayachit wrote:
> 
>> Michael,
>> 
>> I'll try to figure out the install issue. In the mean time, if you're
>> intrested in creating redistrubtable app bundles, refer to
>> http://paraview.org/Wiki/ParaView/Superbuild
>> 
>> Utkarsh
>> 
>> On Thu, May 30, 2013 at 9:20 AM, Michael Schlottke
>> <m.schlottke at aia.rwth-aachen.de> wrote:
>>> Hi Utkarsh,
>>> 
>>> Thanks for the URL. After checking all relevant entries, we still found no possible for the cause of the bug, so back to square one. We then instrumented the plugin code heavily with debug statements, and finally found an answer to our problem: as it turned out, there was a minor bug in the plugin code (related to the ordering of points) that for some reason never materialized when running the plugin with ParaView 3.14, but which caused some serious trouble in 4.0.0. After fixing the bug, the plugin now runs happily with 4.0.0-RC2 and on OS X!
>>> 
>>> Thanks again for your help! It would be great if the "make install" issue could be resolved (if I can help, let me know), since right now I have no way to start ParaView from the OS X gui (I need to go into a terminal and manually execute paraview from there). Creating a symlink to the paraview.app in <builddir>/bin/paraview.app won't work, and neither does copying the paraview.app folder manually.
>>> 
>>> Regards,
>>> 
>>> Michael
>>> 
>>> On May 29, 2013, at 23:22 , Utkarsh Ayachit wrote:
>>> 
>>>> Michael,
>>>> 
>>>> In theory, "make install" should work. OsX can be pretty unforgiving
>>>> with library paths. I'll try to see if I can reproduce the issue and
>>>> track it down.
>>>> 
>>>> As for the segfault, it's hard to say without looking at the code.
>>>> There have been quite a few changes since VTK 6.0. Refer to this:
>>>> http://www.vtk.org/Wiki/VTK/VTK_6_Migration_Guide
>>>> Hopefully that helps.
>>>> 
>>>> Utkarsh
>>>> 
>>>> 
>>>> On Wed, May 29, 2013 at 10:10 AM, Michael Schlottke
>>>> <m.schlottke at aia.rwth-aachen.de> wrote:
>>>>> Hi Utkarsh,
>>>>> 
>>>>> (a) is the location of the paraview.app bundle that is created when building ParaView on OS X and running "make install"
>>>>> (b) is the original build directory
>>>>> 
>>>>> If I go to the build directory and run "./bin/paraview.app/Contents/MacOS/paraview", it actually works, so thank you very much! How come that the "installed" version has problems with duplicate symbols, while the original one doesn't? This seems to render the "make install" command rather useless on OS X…(or maybe its a feature and I just fail to see the purpose).
>>>>> 
>>>>> However, now that the plugin loads correctly, if I try to load a dataset with the reader, ParaView crashes with a segfault: "Segmentation fault: 11"
>>>>> From my plugin's debug output I know that the "RequestData" function returns without problems, but after that there's no more output until the segfault. The exact same plugin works without problems on a Linux machine. The only explanation that I can come up with is that there was a (silent) change from 3.14 to 4.00 that does not manifest in the plugin itself but only later in the pipeline. Can you make anything of this?
>>>>> 
>>>>> Thanks a lot in advance!
>>>>> 
>>>>> Michael
>>>>> 
>>>>> On May 29, 2013, at 15:37 , Utkarsh Ayachit wrote:
>>>>> 
>>>>>> Looks like you have two builds of ParaView:
>>>>>> (a)  /Applications/ParaView 4.0.0-RC2.app/
>>>>>> (b) / /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC2/
>>>>>> 
>>>>>> Which one (a) or (b) was the plugin built against and which one are
>>>>>> you trying to load it in?
>>>>>> 
>>>>>> Utkarsh
>>>>>> 
>>>>>> On Wed, May 29, 2013 at 8:58 AM, Michael Schlottke
>>>>>> <m.schlottke at aia.rwth-aachen.de> wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> We have created a custom reader plugin for our simulation data. On Linux
>>>>>>> using ParaView 3.14 the plugin works without problems. However, we have not
>>>>>>> succeeded to get the plugin to work on Mac OS X:
>>>>>>> 
>>>>>>> When trying to load the plugin in the Plugin Manager, ParaView crashes and
>>>>>>> leaves the following message on the command line:
>>>>>>> 
>>>>>>> objc[54821]: Class vtkCocoaTimer is implemented in both
>>>>>>> /Applications/ParaView
>>>>>>> 4.0.0-RC2.app/Contents/MacOS/./../Libraries/libvtkRenderingOpenGL-pv4.0.1.dylib
>>>>>>> and
>>>>>>> /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC2/lib/libvtkRenderingOpenGL-pv4.0.1.dylib.
>>>>>>> One of the two will be used. Which one is undefined.
>>>>>>> objc[54821]: Class vtkCocoaServer is implemented in both
>>>>>>> /Applications/ParaView
>>>>>>> 4.0.0-RC2.app/Contents/MacOS/./../Libraries/libvtkRenderingOpenGL-pv4.0.1.dylib
>>>>>>> and
>>>>>>> /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC2/lib/libvtkRenderingOpenGL-pv4.0.1.dylib.
>>>>>>> One of the two will be used. Which one is undefined.
>>>>>>> objc[54821]: Class vtkCocoaFullScreenWindow is implemented in both
>>>>>>> /Applications/ParaView
>>>>>>> 4.0.0-RC2.app/Contents/MacOS/./../Libraries/libvtkRenderingOpenGL-pv4.0.1.dylib
>>>>>>> and
>>>>>>> /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC2/lib/libvtkRenderingOpenGL-pv4.0.1.dylib.
>>>>>>> One of the two will be used. Which one is undefined.
>>>>>>> objc[54821]: Class vtkCocoaGLView is implemented in both
>>>>>>> /Applications/ParaView
>>>>>>> 4.0.0-RC2.app/Contents/MacOS/./../Libraries/libvtkRenderingOpenGL-pv4.0.1.dylib
>>>>>>> and
>>>>>>> /Users/mic/.BuiltFromSource/.builds/ParaView-4.0.0-RC2/lib/libvtkRenderingOpenGL-pv4.0.1.dylib.
>>>>>>> One of the two will be used. Which one is undefined.
>>>>>>> libprotobuf ERROR
>>>>>>> /Users/mic/.BuiltFromSource/.sources/ParaView-4.0.0-RC2/ThirdParty/protobuf/vtkprotobuf/src/google/protobuf/descriptor_database.cc:109]
>>>>>>> Symbol name "google.protobuf.NamePart" conflicts with the existing symbol
>>>>>>> "google.protobuf.NamePart".
>>>>>>> libprotobuf FATAL
>>>>>>> /Users/mic/.BuiltFromSource/.sources/ParaView-4.0.0-RC2/ThirdParty/protobuf/vtkprotobuf/src/google/protobuf/descriptor.cc:860]
>>>>>>> CHECK failed: generated_database_->Add(encoded_file_descriptor, size):
>>>>>>> Abort trap: 6
>>>>>>> 
>>>>>>> The used OS X version is 10.7.5, with ParaView 4.0.0-RC2. Compilation was
>>>>>>> done (both plugin and ParaView itself) with clang 3.1.
>>>>>>> 
>>>>>>> Since I wouldn't even know where to start searching for the cause of this
>>>>>>> problem, any help or input is appreciated.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Michael
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Michael Schlottke
>>>>>>> 
>>>>>>> SimLab Highly Scalable Fluids & Solids Engineering
>>>>>>> Jülich Aachen Research Alliance (JARA-HPC)
>>>>>>> RWTH Aachen University
>>>>>>> Wüllnerstraße 5a
>>>>>>> 52062 Aachen
>>>>>>> Germany
>>>>>>> 
>>>>>>> Phone: +49 (241) 80 95188
>>>>>>> Fax: +49 (241) 80 92257
>>>>>>> Mail: m.schlottke at aia.rwth-aachen.de
>>>>>>> Web: http://www.jara.org/jara-hpc
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Paraview-developers mailing list
>>>>>>> Paraview-developers at paraview.org
>>>>>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>>>>>> 
>>>>> 
>>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20130617/d2657119/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pvmac_fix_libpath
Type: application/octet-stream
Size: 1751 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20130617/d2657119/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20130617/d2657119/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2308 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20130617/d2657119/attachment-0001.bin>

More information about the Paraview-developers mailing list