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

Albert Godfrind albert.godfrind at oracle.com
Mon Dec 28 08:30:51 PST 2015


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

--
 <http://www.oracle.com/>
Albert Godfrind | Geospatial technologies | Tel: +33 4 93 00 80 67 | Mobile: +33 6 09 97 27 23 | Skype: albert-godfrind <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 <http://www.apress.com/9781590598993>
 <http://www.locationintelligence.net/dc/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20151228/243173ea/attachment-0001.html>


More information about the pdal mailing list