The routines to find and link to gdal are broken for me after the switch to cmake.

Can you try to set GDAL_HOME ? <a hr

Tried that, did not make any difference. In my case I can see that <code class="notran

thanks <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-u

FindGDAL.cmake fails if path contains lib about liblas HOT 5 CLOSED

liblas commented on June 15, 2024

FindGDAL.cmake fails if path contains lib

from liblas.

Comments (5)

mloskot commented on June 15, 2024

Can you try to set GDAL_HOME?

https://github.com/libLAS/libLAS/blob/master/cmake/modules/FindGDAL.cmake#L157-L161

from liblas.

springmeyer commented on June 15, 2024

Tried that, did not make any difference. In my case I can see that gdal-config is being found fine (its on PATH) but it is the custom parsing going on within https://github.com/libLAS/libLAS/blob/master/cmake/modules/FindGDAL.cmake#L223-L251 that is causing the problem.

Additionally, I'm trying to link to libgdal.a rather than dylib so the hardcoding at

libLAS/cmake/modules/FindGDAL.cmake

Line 248 in 59709b3

    
           SET(GDAL_LIBRARY ${GDAL_LINK_DIRECTORIES}/lib${GDAL_LIB_NAME}.dylib CACHE STRING INTERNAL)

is breaking for me. I'm working around this for now by manually patching like:

--- cmake/modules/FindGDAL.cmake_   2014-04-06 14:51:52.000000000 -0700
+++ cmake/modules/FindGDAL.cmake    2014-04-06 14:51:59.000000000 -0700
@@ -164,7 +164,8 @@
         ENDIF()

         IF(APPLE)
-            SET(GDAL_LIBRARY ${GDAL_LINK_DIRECTORIES}/lib${GDAL_LIB_NAME}.dylib CACHE STRING INTERNAL)
+            SET(GDAL_LIBRARY "/Users/dane/projects/mapnik-packaging/osx/out/build-cpp03-libstdcpp-x86_64/lib/libgdal.a" CACHE STRING INTERNAL)
+            #SET(GDAL_LIBRARY ${GDAL_LINK_DIRECTORIES}/lib${GDAL_LIB_NAME}.dylib CACHE STRING INTERNAL)
         ELSE()
             SET(GDAL_LIBRARY ${GDAL_LINK_DIRECTORIES}/lib${GDAL_LIB_NAME}.so CACHE STRING INTERNAL)
         ENDIF()

from liblas.

mloskot commented on June 15, 2024

To enable selection between .dylib/.so and .a, new option GDAL_USE_STATIC_LIB may be needed, I think.

Would that solve your problem?

from liblas.

springmeyer commented on June 15, 2024

thanks @mloskot - I've created a new issue to clarify the libgdal.a linking issues: #33

from liblas.

mloskot commented on June 15, 2024

Looks we can close this one too.

from liblas.

Recommend Projects