Bug report #3376

CMake cannot find GDAL or GEOS

Added by sharpie - almost 11 years ago. Updated almost 11 years ago.

Assignee:nobody -
Affected QGIS version: Regression?:No
Operating System:OS X Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:13436


With QGIS 1.6.0, the CMake scripts seem to be unable to detect the GEOS or GRASS libraries even though they are accessible in /usr/local/lib.

Running cmake .., I get:

CMake Error at cmake/FindGEOS.cmake:163 (MESSAGE):
  Could not find GEOS
Call Stack (most recent call first):
  CMakeLists.txt:141 (FIND_PACKAGE)

-- Configuring incomplete, errors occurred!

It is odd that CMake discovers the headers, but fails to find the library.

Even stranger, is that if I add a tracing statement after line 135 of FindGEOS.cmake:

  MESSAGE("Library should be set to: ${GEOS_LINK_DIRECTORIES}/lib${GEOS_LIB_NAME}.dylib")

I see a message printed out that has the correct path to the library, yet GEOS_LIBRARY is still set to GEOS_LIBRARY-NOTFOUND.

If I replace the call to SET with a call to FIND_LIBRARY, everything works:


Attached is a patch that makes this change for FindGEOS.cmake and FindGDAL.cmake. I don't have William Kyngesburye's frameworks installed so I can't judge whether or not these changes negatively impact his build process.

Version 1.5.0 builds from source just fine.

qgis_1.6.0_cmake.patch Magnifier - Patch to add FORCE to SET commands for libraries if those libraries are currently NOTFOUND (1.23 KB) sharpie -, 2010-12-30 03:11 PM


#1 Updated by William Kyngesburye almost 11 years ago

FIND_LIBRARY at that point is not right, since it completely ignores any geos-|gdal-config values. I suspect that SET is not setting because in the framework test GEOS_|GDAL_LIBRARY will be left empty, not unset, when it fails. SET here then doesn't set it (it sets a variable only if it's unset, and maybe empty is not the same as unset), though FIND_LIBRARY will.

Try adding the FORCE keyword after INTERNAL in the SET.

#2 Updated by sharpie - almost 11 years ago

Adding FORCE to SET worked.

Additionally, I noticed that many of the SET commands are of the form:

SET( <variable> <value> CACHE STRING INTERNAL)

This looks like an attempt to set the <type> of the variable to both STRING and INTERNAL. According to cmake --help-command SET:

The value for <type> may be one of

         FILEPATH = File chooser dialog.
         PATH     = Directory chooser dialog.
         STRING   = Arbitrary string.
         BOOL     = Boolean ON/OFF checkbox.
         INTERNAL = No GUI entry (used for persistent variables).

I don't know if specifying two types is causing any problems, but it is probably not working as intended. For the two APPLE SET commands, I replaced STRING INTERNAL with FILEPATH "A Description" FORCE.

#3 Updated by William Kyngesburye almost 11 years ago

  • Resolution set to fixed
  • Status changed from Open to Closed

Fixed in 0aa434a3 (SVN r14985) for now. I need to figure out better logic and add some other improvements to the framework check so this fix isn't needed.

For the extra INTERNAL, maybe leftovers from an earlier version of the cmake files, or just misused option. It doesn't cause an error, "INTERNAL" is just taken as the docstring. I don't know what the original author intended.

Also available in: Atom PDF