[vtkusers] Don't build vtkproj4?
Chris Marsh
chris.marsh at usask.ca
Tue Jan 30 16:26:38 EST 2018
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/1f992521/attachment.html>
More information about the vtkusers
mailing list