Bug report #3376
CMake cannot find GDAL or GEOS
Status: | Closed | ||
---|---|---|---|
Priority: | Low | ||
Assignee: | nobody - | ||
Category: | Build/Install | ||
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 |
Description
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:
GEOS_INCLUDE_DIR=/usr/local/include GEOS_LIBRARY=GEOS_LIBRARY-NOTFOUND 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:
IF (APPLE) SET(GEOS_LIBRARY ${GEOS_LINK_DIRECTORIES}/lib${GEOS_LIB_NAME}.dylib CACHE STRING INTERNAL) MESSAGE("Library should be set to: ${GEOS_LINK_DIRECTORIES}/lib${GEOS_LIB_NAME}.dylib") ELSE (APPLE)
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:
IF (APPLE) FIND_LIBRARY(GEOS_LIBRARY ${GEOS_LIB_NAME} PATHS ${GEOS_LINK_DIRECTORIES}/lib) ELSE (APPLE)
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.
History
#1 Updated by William Kyngesburye almost 14 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 14 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 14 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.