Don't build vtkproj4?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Don't build vtkproj4?

chrism
Hi,

Is there a way to stop vtkproj4 from being built? It seems to be conflicting with another version of proj4 I am building for my application.

Cheers
Chris

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

Ben Boeckel
On Tue, Jan 09, 2018 at 17:32:09 -0600, Chris Marsh wrote:
> Is there a way to stop vtkproj4 from being built? It seems to be
> conflicting with another version of proj4 I am building for my application.

You can tell VTK to use an external proj4 using VTK_USE_SYSTEM_libproj4.

--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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

chrism
Great, thanks!

I am custom building proj4. What is the best way to tell VTK's CMake where to look for proj4?

Cheers
Chris

On 10 January 2018 at 06:58, Ben Boeckel <[hidden email]> wrote:
On Tue, Jan 09, 2018 at 17:32:09 -0600, Chris Marsh wrote:
> Is there a way to stop vtkproj4 from being built? It seems to be
> conflicting with another version of proj4 I am building for my application.

You can tell VTK to use an external proj4 using VTK_USE_SYSTEM_libproj4.

--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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

Ben Boeckel
On Wed, Jan 10, 2018 at 09:24:53 -0600, Chris Marsh wrote:
> Great, thanks!
>
> I am custom building proj4. What is the best way to tell VTK's CMake where
> to look for proj4?

The find module seems to use the LIBPROJ4_DIR environment variable if
available. It should be the install prefix of proj4.

--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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

chrism
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.

Any suggestions?  

On 10 January 2018 at 09:36, Ben Boeckel <[hidden email]> wrote:
On Wed, Jan 10, 2018 at 09:24:53 -0600, Chris Marsh wrote:
> Great, thanks!
>
> I am custom building proj4. What is the best way to tell VTK's CMake where
> to look for proj4?

The find module seems to use the LIBPROJ4_DIR environment variable if
available. It should be the install prefix of proj4.

--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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

Ben Boeckel
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

chrism
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
University of Saskatchewan

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

Aashish Chaudhary-2
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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
University of Saskatchewan

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

Dan Lipsa-2
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 <[hidden email]> wrote:
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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.

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

chrism
Hi Dan,

I'm trying to figure out the issue I detail here:

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 <[hidden email]> 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 <[hidden email]> wrote:
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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.

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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



_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

Dan Lipsa-2
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 <[hidden email]> wrote:
Hi Dan,

I'm trying to figure out the issue I detail here:

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 <[hidden email]> 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 <[hidden email]> wrote:
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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.

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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




_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

chrism
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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Dan,

I'm trying to figure out the issue I detail here:

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 <[hidden email]> 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 <[hidden email]> wrote:
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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.

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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





_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

chrism
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Dan,

I'm trying to figure out the issue I detail here:

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 <[hidden email]> 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 <[hidden email]> wrote:
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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.

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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






_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

Dan Lipsa-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Dan,

I'm trying to figure out the issue I detail here:

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 <[hidden email]> 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 <[hidden email]> wrote:
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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.

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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







_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

chrism
Hi,
That is great to hear!
Cheers
Chris


On 30 January 2018 at 16:35, Dan Lipsa <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Dan,

I'm trying to figure out the issue I detail here:

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 <[hidden email]> 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 <[hidden email]> wrote:
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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.

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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








_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

chrism
Hi all,

Just a note this appears to have been fixed as of (at least) 8.1.1 and I'm no longer encountering this issues.
Thanks very much for resolving this.

Cheers
Chris



On 30 January 2018 at 16:59, Chris Marsh <[hidden email]> wrote:
Hi,
That is great to hear!
Cheers
Chris


On 30 January 2018 at 16:35, Dan Lipsa <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Dan,

I'm trying to figure out the issue I detail here:

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 <[hidden email]> 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 <[hidden email]> wrote:
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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.

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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









_______________________________________________
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://public.kitware.com/mailman/listinfo/vtkusers
Reply | Threaded
Open this post in threaded view
|

Re: Don't build vtkproj4?

Dan Lipsa-2
Great! Thanks for testing this Chris.

Best,
Dan


On Tue, Jul 3, 2018 at 1:58 PM Chris Marsh <[hidden email]> wrote:
Hi all,

Just a note this appears to have been fixed as of (at least) 8.1.1 and I'm no longer encountering this issues.
Thanks very much for resolving this.

Cheers
Chris



On 30 January 2018 at 16:59, Chris Marsh <[hidden email]> wrote:
Hi,
That is great to hear!
Cheers
Chris


On 30 January 2018 at 16:35, Dan Lipsa <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Dan,

I'm trying to figure out the issue I detail here:

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 <[hidden email]> 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 <[hidden email]> wrote:
Dan Lipsa made last changes perhaps he may have some suggestions. 

- aashish

On Thu, Jan 11, 2018 at 7:41 PM Chris Marsh <[hidden email]> 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.

On 11 January 2018 at 13:29, Ben Boeckel <[hidden email]> 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









_______________________________________________
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://public.kitware.com/mailman/listinfo/vtkusers