[vtkusers] Don't build vtkproj4?

Chris Marsh chris.marsh at usask.ca
Tue Jan 30 17:59:53 EST 2018 

Hi,
That is great to hear!
Cheers
Chris


On 30 January 2018 at 16:35, Dan Lipsa <dan.lipsa at kitware.com> wrote:

> Hi Chris,
> Thanks for investigating this.
> Indeed, looking the the so file, there are some symbols that we are not
> mangling, which cause the problems you've seen.
> I believe this was caused by updating of the version of the library we are
> including without updating the list of symbols we are mangling.
> We'll fix this shortly,
>
> Dan
>
>
> On Tue, Jan 30, 2018 at 4:26 PM, Chris Marsh <chris.marsh at usask.ca> wrote:
>
>> Hi all,
>>
>> I have some updates on this. I recently discovered the LD_DEBUG=bindings
>> linker tool, so I can see what is happening.
>>
>> There appear to be many cases where either the proj4 library I built or
>> my executable bind to symbols in libvtkproj.
>>
>> A few examples shown here. 'After patch elf' is when I use patchelf with
>> --replace-needed to remove libvtkproj.so
>>
>> As built
>>  21340: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_prime_meridians'
>>      21340: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_list'
>>      21340: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/bin/Release/CHM [0]: normal symbol
>> `stdout' [GLIBC_2.2.5]
>>      21340: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_ellps'
>>      21340: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_datums'
>>
>> After patch elf
>>
>> 21259: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_prime_meridians'
>>      21259: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_list'
>>      21259: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/bin/Release/CHM [0]: normal symbol
>> `stdout' [GLIBC_2.2.5]
>>      21259: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_ellps'
>>      21259: binding file /home/cbm038/build-release/lib/proj4/lib/libproj.so.12
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_datums'
>>
>>
>> Another example:
>>
>> As built
>>  21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/bin/Release/CHM [0]: normal symbol
>> `stderr' [GLIBC_2.2.5]
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_units'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_aea'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_s_aea'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_aeqd'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_s_aeqd'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_airy'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_s_airy'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_aitoff'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_s_aitoff'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_alsk'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_s_alsk'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_apian'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `pj_s_apian'
>>      21340: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_august'
>>
>>
>> after patchelf
>>
>>  21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_units'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_aea'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_s_aea'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_aeqd'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_s_aeqd'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_airy'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_s_airy'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_aitoff'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_s_aitoff'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_alsk'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_s_alsk'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_apian'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_s_apian'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1 [0]:
>> normal symbol `vtk_pj_august'
>>      21259: binding file /home/cbm038/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>> [0] to /home/cbm038/build-release/lib/proj4/lib/libproj.so.12 [0]:
>> normal symbol `pj_s_august'
>>
>>
>> Building VTK with system proj4 does correctly 'solve' the problem.
>>
>> Can provide more details if required.
>>
>> Cheers
>> Chris
>>
>> On 16 January 2018 at 13:17, Chris Marsh <chris.marsh at usask.ca> wrote:
>>
>>> Hi all,
>>>
>>> Thanks for the detailed thoughts.
>>>
>>> Is the message you are getting from proj saying that the string you pass
>>>> is not valid?
>>>>
>>> Correct. However, I've verified with both the GDAL and proj4 mailing
>>> lists that the string is correct. The string is actually output from proj4
>>> itself, so I have substantial confidence in it.
>>>
>>>
>>>> Maybe somebody overrides that memory?
>>>> Try run your program though valgrind and/or comment out chunks of code
>>>> trying to see who causes your error.
>>>>
>>> Valgrind and the Intel memory tools show no memory corruption.
>>>
>>> Is VTK in the call stack for the errors you described? If not, I think
>>>> it is not involved in the errors.
>>>
>>> GDAL, as I understand, dynamically opens the .so at runtime, so it's
>>> tough to figure out exactly what it is doing. Looking at the backtrace in
>>> gdb shows that it appears to be calling into the system proj4 before it
>>> segfaults.
>>>
>>> If I use patchelf to strip the vtkproj4 reference, it is then fine.  If
>>> use patchelf to strip the system proj4 leaving the vtkproj4, I get the same
>>> error and segfault.
>>>
>>> I *suspect* GDAL is doing the wrong thing here and loading the wrong
>>> library for some calls. This is all to say, I don't think it's a VTK
>>> problem per se, but is for whatever reason, conflicting on this system.
>>>
>>> Further weirdness is that on the machines this works 100%, I don't see
>>> any reference to libvtkproj4.
>>>
>>> I'll follow up after I rebuild everything again with the VTK system
>>> proj4.
>>>
>>> Thanks very much,
>>>
>>> Cheers
>>> Chris
>>>
>>>
>>> University of Saskatchewan
>>>
>>> On 15 January 2018 at 10:03, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>>>
>>>> Hi Chris,
>>>> Is VTK in the call stack for the errors you described? If not, I think
>>>> it is not involved in the errors.
>>>>
>>>> vtkproj should not interfere with proj, but you can make VTK use the
>>>> system proj with the method described earlier.
>>>>
>>>> Is the message you are getting from proj saying that the string you
>>>> pass is not valid? Maybe somebody overrides that memory?
>>>> Try run your program though valgrind and/or comment out chunks of code
>>>> trying to see who causes your error.
>>>> Hope this helps,
>>>> Dan
>>>>
>>>>
>>>>
>>>> On Fri, Jan 12, 2018 at 3:32 PM, Chris Marsh <chris.marsh at usask.ca>
>>>> wrote:
>>>>
>>>>> Hi Dan,
>>>>>
>>>>> I'm trying to figure out the issue I detail here:
>>>>> http://osgeo-org.1560.x6.nabble.com/Failed-to-initialize-PRO
>>>>> J-4-with-quot-quot-td5338323.html
>>>>> http://osgeo-org.1560.x6.nabble.com/gdal-dev-ERROR-6-Failed-
>>>>> to-initialize-PROJ-4-with-quot-quot-td5338107.html
>>>>>
>>>>> Effectively the error is that GDAL seems to call the incorrect
>>>>> library/something happens, and the projection fails.
>>>>>
>>>>> In an effort to resolve this I was looking at my binary via LDD and
>>>>> found
>>>>> $ ldd ~/build-release/bin/Release/CHM | grep proj4
>>>>>         libvtkproj4-8.0.so.1 => /home/cmarsh/build-release/lib/VTK/lib/libvtkproj4-8.0.so.1
>>>>> (0x00002b517aa36000)
>>>>>         libproj.so.0 => /home/cmarsh/build-release/lib/proj4/lib/libproj.so.0
>>>>> (0x00002b51944d2000)
>>>>>
>>>>> If I use patchelf (https://github.com/NixOS/patchelf) to strip
>>>>> libvtkproj4-8.0.so.1 from my binary, my code runs without the error.
>>>>>
>>>>> I don't quite understand why I don't have this problem on other
>>>>> machines though. Looking at other machines I compile on (using a custom VTK
>>>>> build) I don't see any reference to the VTK libproj4 via ldd.
>>>>>
>>>>> Thus I attributed the error to vtkproj4 inclusion. However if you
>>>>> mangle names, then I agree I don't understand why this is happening.
>>>>>
>>>>> Cheers
>>>>> Chris
>>>>>
>>>>>
>>>>> On 12 January 2018 at 09:35, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>>>>>
>>>>>> Chris,
>>>>>>
>>>>>> 1. Going back to the beginning of the thread, I don't understand why
>>>>>> vtklibproj conflicts with another proj, given that we mangle all names. Can
>>>>>> you send us the errors.
>>>>>>
>>>>>> 2. If you do want to build with the system proj4
>>>>>>
>>>>>> Can you send up the output of:
>>>>>> cat CMakeCache.txt | grep LIBPROJ
>>>>>>
>>>>>> This is what I have:
>>>>>> LIBPROJ4_INCLUDE_DIR:PATH=/usr/include
>>>>>> LIBPROJ4_LIBRARIES:FILEPATH=/usr/lib/x86_64-linux-gnu/libproj.so.12
>>>>>> LIBPROJ_BINDIR:PATH=bin
>>>>>> LIBPROJ_DATADIR:PATH=share/proj
>>>>>> LIBPROJ_DOCDIR:PATH=doc/proj
>>>>>> LIBPROJ_INCLUDEDIR:PATH=include
>>>>>> LIBPROJ_LIBDIR:PATH=lib
>>>>>> LIBPROJ_M_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libm.so
>>>>>> LIBPROJ_USE_THREAD:BOOL=ON
>>>>>> //Use system-installed LIBPROJ4
>>>>>> VTK_USE_SYSTEM_LIBPROJ4:BOOL=ON
>>>>>> //ADVANCED property for variable: LIBPROJ4_INCLUDE_DIR
>>>>>> LIBPROJ4_INCLUDE_DIR-ADVANCED:INTERNAL=1
>>>>>> //ADVANCED property for variable: LIBPROJ4_LIBRARIES
>>>>>> LIBPROJ4_LIBRARIES-ADVANCED:INTERNAL=1
>>>>>> //MODIFIED property for variable: LIBPROJ4_LIBRARIES
>>>>>> LIBPROJ4_LIBRARIES-MODIFIED:INTERNAL=ON
>>>>>> //ADVANCED property for variable: LIBPROJ_BINDIR
>>>>>> LIBPROJ_BINDIR-ADVANCED:INTERNAL=1
>>>>>> //ADVANCED property for variable: LIBPROJ_DATADIR
>>>>>> LIBPROJ_DATADIR-ADVANCED:INTERNAL=1
>>>>>> //ADVANCED property for variable: LIBPROJ_DOCDIR
>>>>>> LIBPROJ_DOCDIR-ADVANCED:INTERNAL=1
>>>>>> //ADVANCED property for variable: LIBPROJ_INCLUDEDIR
>>>>>> LIBPROJ_INCLUDEDIR-ADVANCED:INTERNAL=1
>>>>>> //ADVANCED property for variable: LIBPROJ_LIBDIR
>>>>>> LIBPROJ_LIBDIR-ADVANCED:INTERNAL=1
>>>>>> //ADVANCED property for variable: LIBPROJ_M_LIB
>>>>>> LIBPROJ_M_LIB-ADVANCED:INTERNAL=1
>>>>>> //ADVANCED property for variable: LIBPROJ_USE_THREAD
>>>>>> LIBPROJ_USE_THREAD-ADVANCED:INTERNAL=1
>>>>>> //ADVANCED property for variable: VTK_USE_SYSTEM_LIBPROJ4
>>>>>> VTK_USE_SYSTEM_LIBPROJ4-ADVANCED:INTERNAL=1
>>>>>> //MODIFIED property for variable: VTK_USE_SYSTEM_LIBPROJ4
>>>>>> VTK_USE_SYSTEM_LIBPROJ4-MODIFIED:INTERNAL=ON
>>>>>>
>>>>>>
>>>>>> Make sure
>>>>>> LIBPROJ4_INCLUDE_DIR
>>>>>> LIBPROJ4_LIBRARIES
>>>>>> VTK_USE_SYSTEM_LIBPROJ4
>>>>>> have the correct values.
>>>>>>
>>>>>> All those are cmake variables, you change them using ccmake or
>>>>>> cmake-gui.
>>>>>> After that you call:
>>>>>>
>>>>>> cmake .
>>>>>> make
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 12, 2018 at 9:15 AM, Aashish Chaudhary <
>>>>>> aashish.chaudhary at kitware.com> wrote:
>>>>>>
>>>>>>> Dan Lipsa made last changes perhaps he may have some suggestions.
>>>>>>>
>>>>>>> - aashish
>>>>>>>
>>>>>>> On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <chris.marsh at usask.ca>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Looks like something is setting
>>>>>>>> PROJ4_INCLUDE_DIR
>>>>>>>> PROJ4_LIBRARY
>>>>>>>> to the system's proj4. I use a custom findproj4 that only looks
>>>>>>>> where I tell it.
>>>>>>>>
>>>>>>>> then I see that
>>>>>>>> LIB_FILES:INTERNAL
>>>>>>>> contains vtkproj4
>>>>>>>> LIB_FILES just holds all my 3rd party libraries I need to link
>>>>>>>> against.
>>>>>>>>
>>>>>>>> Chris Marsh
>>>>>>>> PhD Candidate
>>>>>>>> chrismarsh.ca
>>>>>>>>
>>>>>>>> 121 Research Drive
>>>>>>>> <https://maps.google.com/?q=121+Research+Drive+University+of+Saskatchewan&entry=gmail&source=g>
>>>>>>>> University of Saskatchewan
>>>>>>>> <https://maps.google.com/?q=121+Research+Drive+University+of+Saskatchewan&entry=gmail&source=g>
>>>>>>>>
>>>>>>>> On 11 January 2018 at 13:29, Ben Boeckel <ben.boeckel at kitware.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Thu, Jan 11, 2018 at 11:41:40 -0600, Chris Marsh wrote:
>>>>>>>>> > Thanks for the details. This doesn't seem to be working for me
>>>>>>>>> though. I've
>>>>>>>>> > tried passing VTK_USE_SYSTEM_libproj4 to cmake on the command
>>>>>>>>> line as well
>>>>>>>>> > as defining it as a CXXFLAG='-D VTK_USE_SYSTEM_libproj4",
>>>>>>>>> however neither
>>>>>>>>> > works. I still see the vtklibproj4 in the output of ldd.
>>>>>>>>>
>>>>>>>>> CMake should be getting the flag. If you do:
>>>>>>>>>
>>>>>>>>>     grep -i proj4 CMakeCache.txt
>>>>>>>>>
>>>>>>>>> do any variables stand out as potentially being set to use the
>>>>>>>>> internal
>>>>>>>>> one?
>>>>>>>>>
>>>>>>>>> --Ben
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Powered by www.kitware.com
>>>>>>>>
>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>
>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>
>>>>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> https://vtk.org/mailman/listinfo/vtkusers
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtkusers/attachments/20180130/bea9e569/attachment-0001.html>

More information about the vtkusers mailing list