[vtkusers] Don't build vtkproj4?

Chris Marsh chris.marsh at usask.ca
Fri Jan 12 15:32:51 EST 2018


Hi Dan,

I'm trying to figure out the issue I detail here:
http://osgeo-org.1560.x6.nabble.com/Failed-to-initialize-PROJ-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/20180112/3d9b2a8e/attachment.html>


More information about the vtkusers mailing list