[pdal] Unable to build PDAL 1.1.0: "Could NOT find GDAL (missing: GDAL_INCLUDE_DIR) "

Howard Butler howard at hobu.co
Mon Jan 4 11:58:30 PST 2016


Albert,

If you can make a patch to the FindGDAL.cmake that does this, I'm happy to include it. We should also upstream it to Kitware, as I think they use our FindGDAL.cmake that was originally written by Mateusz.

gdalinfo --version doesn't seem to output any install location information for me for either GDAL 1.11.x or GDAL 2.0.x, so I'm not sure about how to implement this patch myself.

Howard

> On Jan 4, 2016, at 5:47 AM, Albert Godfrind <albert.godfrind at oracle.com> wrote:
> 
> I was finally able to progress by setting the variables explicitly on the cmake call:
> 
> cmake -DGDAL_CONFIG=$GDAL_HOME/bin/gdal-config -DGDAL_INCLUDE_DIR=$GDAL_HOME/include -DGDAL_LIBRARY=$GDAL_HOME/lib/libgdal.so ..
> 
> That now completes successfully, and all the paths are correct.
> 
> IMO using gdal-config to find about the gdal environment is not the right approac. The information it provides (prefix, library etc) come all from the server where gdal was built. That information it totally different from the one where gdal is installed. A better approach would be to use “gdalinfo —version” to find out the version being used, and extract the directory location for include and lib from the full path of the gdalinfo command (or from the GDAL_HOME environment variable if one is set). 
> 
> Albert
> 
>> On 28-Dec-2015, at 17:30, Albert Godfrind <albert.godfrind at oracle.com> wrote:
>> 
>> Thanks Howard.
>> 
>> Removing he dependency on boost would be great. The only package I found in the rpm repositories is 1.41 which pdal says is too old. So I had to build it from sources and just picked up the latest (1.60) …
>> 
>>> PDAL's configure-time GDAL detection needs to support GDAL 2.0. Software-wise, GDAL 2.0 should be no problem except for maybe some deprecation warnings. PDAL currently only supports 1.11.x., however. I will make a patch to fix this and let you know.
>> 
>> There may be something else. I just tried again after setting GDAL_HOME to 1.10, and I still fail the same way:
>> 
>> $ export GDAL_HOME=/opt/gdal/gdal-1.10
>> $ cmake ..
>> -- Boost version: 1.60.0
>> -- Found the following Boost libraries:
>> --   program_options
>> --   iostreams
>> --   filesystem
>> --   system
>> --   thread
>> -- Could NOT find GDAL (missing:  GDAL_INCLUDE_DIR) (Required is at least version "1.9.0")
>> CMake Error at cmake/gdal.cmake:12 (message):
>>   GDAL support is required
>> Call Stack (most recent call first):
>>   CMakeLists.txt:219 (include)
>> 
>> Looking at the code in FindGDAL.cmake and adding a bit of debugging, I see that it does find GDAL (sets GDAL_FOUND to TRUE), but it still uses the gdal-config from my default environment (i.e. version 2.0).
>> 
>> This block of code does not perform as expected:
>> 
>>     # Try to use GDAL_HOME location if specified
>>     IF($ENV{GDAL_HOME})
>>         SET(GDAL_CONFIG_PREFER_PATH
>>             "$ENV{GDAL_HOME}/bin" CACHE STRING "Search for gdal-config program in preferred location")
>>     ENDIF()
>> 
>> That is because of the incorrect way of testing environment variables. It should properly read:
>> 
>>     # Try to use GDAL_HOME location if specified
>>     IF(DEFINED ENV{GDAL_HOME})
>>         SET(GDAL_CONFIG_PREFER_PATH
>>             "$ENV{GDAL_HOME}/bin" CACHE STRING "Search for gdal-config program in preferred location")
>>     ENDIF()
>> 
>> Then GDAL_CONFIG_PREFEER_PATH gets correctly set.
>> 
>> Then again the real cause of the error is here:
>> 
>>         FIND_PATH(GDAL_INCLUDE_DIR
>>             gdal.h 
>>             PATH_PREFIXES gdal
>>             PATHS
>>             ${GDAL_PREFIX}/include/gdal
>>             ${GDAL_PREFIX}/include
>>             /usr/local/include 
>>             /usr/include)
>> 
>> None of the gdal builds I have come with the includes (gdal.h is nowhere to be found). All I have is the shared libraries (also for the plugins) and the command-line tools (and also the data bit).
>> 
>> Another point: the goal-config tool contains the configuration when and where gdal was built. In other words "gdal-config —libs” returns the location of the libraries as they were on the system where GDAL was built, and subsequently GDAL_LIBRARY is set to an invalid location too, definitely not the one used in the current GDAL installation.
>> 
>> Albert
>> 
>> 
>>> On 28-Dec-2015, at 15:59, Howard Butler <howard at hobu.co> wrote:
>>> 
>>> 
>>>> On Dec 28, 2015, at 8:22 AM, Albert Godfrind <albert.godfrind at oracle.com> wrote:
>>>> 
>>>> I am trying to build the latest GDAL on Linux. The cmake stage fails like this:
>>>> 
>>>> $ cmake -G "Unix Makefiles"  ../
>>>> -- Boost version: 1.60.0
>>> 
>>> /me groans. There's a boost 1.60 now? Consider this notice that it is a medium term goal of the PDAL project to eliminate its dependence on externally available Boost before its 2.0 release. Now that C++11 is quite stable just about everywhere, the impetus to reach for Boost for everything is not there anymore for PDAL. Their project release management leaves much to be desired, and because of it, packaging maintainers lag many versions behind current releases. 
>>> 
>>>> -- Could NOT find GDAL (missing:  GDAL_INCLUDE_DIR) (Required is at least version "1.9.0")
>>>> CMake Error at cmake/gdal.cmake:13 (message):
>>> 
>>>> I have gdal installed (version 2.0). It looks like it wants me to define GDAL_INCLUDE_DIR but to what location ? I tried setting up to the lib directory in my installation. I also tried defining GDAL_HOME and even GDAL_LIBRARY all to no effect.
>>> 
>>>> Any idea what I am doing wrong ?
>>> 
>>> PDAL's configure-time GDAL detection needs to support GDAL 2.0. Software-wise, GDAL 2.0 should be no problem except for maybe some deprecation warnings. PDAL currently only supports 1.11.x., however. I will make a patch to fix this and let you know.
>>> 
>>> Howard
>>> 
>>> _______________________________________________
>>> pdal mailing list
>>> pdal at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/pdal
>> 
>> --
>> 
>> Albert Godfrind | Geospatial technologies | Tel: +33 4 93 00 80 67 | Mobile: +33 6 09 97 27 23 | Skype: albert-godfrind
>> Oracle Server Technologies
>> 400 Av. Roumanille, BP 309  | 06906 Sophia Antipolis cedex | France
>> Everything you ever wanted to know about Oracle Spatial
>> 
>> 
>> 
>> 
>> _______________________________________________
>> pdal mailing list
>> pdal at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pdal
> 
> --
> 
> Albert Godfrind | Geospatial technologies | Tel: +33 4 93 00 80 67 | Mobile: +33 6 09 97 27 23 | Skype: albert-godfrind
> Oracle Server Technologies
> 400 Av. Roumanille, BP 309  | 06906 Sophia Antipolis cedex | France
> Everything you ever wanted to know about Oracle Spatial
> 
> 
> 
> 
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pdal



More information about the pdal mailing list