[vtkusers] Don't build vtkproj4?

Chris Marsh chris.marsh at usask.ca
Tue Jan 16 14:17:08 EST 2018


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/20180116/7f4fd820/attachment.html>


More information about the vtkusers mailing list