Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fringe cmake can't find GDAL #9

Open
jlmaurer opened this issue Apr 21, 2020 · 12 comments
Open

Fringe cmake can't find GDAL #9

jlmaurer opened this issue Apr 21, 2020 · 12 comments

Comments

@jlmaurer
Copy link

jlmaurer commented Apr 21, 2020

Building fringe using:
CXX=g++ cmake -DCMAKE_INSTALL_PREFIX=../install ../src/fringe
on "Ubuntu 18.04.4 LTS", where file structure is
Fringe
build
src
fringe
install

I get the following error message:

CMake Error at /usr/local/home/jlmd9g/software/minicondda3/envs/fringe/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
Could NOT find GDAL: Found unsuitable version "2.2.3", but required is at
least "3.0" (found
/usr/local/home/jlmd9g/software/minicondda3/envs/fringe/lib/libgdal.so)
Call Stack (most recent call first):
/usr/local/home/jlmd9g/software/minicondda3/envs/fringe/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:443 (_FPHSA_FAILURE_MESSAGE)
cmake/FindGDAL.cmake:287 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:32 (FIND_PACKAGE)

-- Configuring incomplete, errors occurred!
See also "/usr/local/home/jlmd9g/software/FRiNGE/build/CMakeFiles/CMakeOutput.log".

But:
gdal-config --prefix
/usr/local/home/jlmd9g/software/minicondda3/envs/fringe
gdal-config --version
3.0.4
gdal-config --cflags
-I/usr/local/home/jlmd9g/software/minicondda3/envs/fringe/include
gdal-config --libs
-L/usr/local/home/jlmd9g/software/minicondda3/envs/fringe/lib -lgdal

I've got GDAL_DIR and GDAL_ROOT specified to the same directory:
echo $GDAL_DIR
/usr/local/home/jlmd9g/software/minicondda3/envs/fringe//lib

in which is the .so files:
ls /usr/local/home/jlmd9g/software/minicondda3/envs/fringe//lib/libgdal*

/usr/local/home/jlmd9g/software/minicondda3/envs/fringe//lib/libgdal.a
/usr/local/home/jlmd9g/software/minicondda3/envs/fringe//lib/libgdal.so
/usr/local/home/jlmd9g/software/minicondda3/envs/fringe//lib/libgdal.so.26
/usr/local/home/jlmd9g/software/minicondda3/envs/fringe//lib/libgdal.so.26.0.4

Any ideas?

@piyushrpt
Copy link
Member

What is the version number in

/usr/local/home/jlmd9g/software/minicondda3/envs/fringe/include/gdal_version.h

@piyushrpt
Copy link
Member

I would also check the cmake config output - I suspect its loading gdal.h from a different location than the lib and reporting the mismatch.

@jlmaurer
Copy link
Author

jlmaurer commented Apr 21, 2020

less /usr/local/home/jlmd9g/software/minicondda3/envs/fringe/include/gdal_version.h:
...
# define GDAL_RELEASE_NAME "3.0.4"
...
Based on this page, it looks like cmake may search the default path before searching the path at the environment variable, and since gdal exists at the default path location on my system, it takes that one first.

The relevant lines from FindGDAL.cmake:

197 find_path(GDAL_INCLUDE_DIR gdal.h
198   HINTS
199     ENV GDAL_DIR
200     ENV GDAL_ROOT
201   PATH_SUFFIXES
202      include/gdal
203      include/GDAL
204      include
205      )

If this is true, requiring cmake to look in the specified ENV instead of the default first should fix the problem.

@piyushrpt
Copy link
Member

So

GDAL_DIR=/usr/local/home/jlmd9g/software/minicondda3/envs/fringe CXX=g++ cmake -DCMAKE_INSTALL_PREFIX=../install ../src/fringe

doesn't work? What shell are you using?

@jlmaurer
Copy link
Author

jlmaurer commented Apr 21, 2020

Just as a follow-up, cmake is definitely using gdal at the default location:
grep '2.2.3' /usr/include/gdal/gdal_version.h
# define GDAL_RELEASE_NAME "2.2.3"

And yes, that command gives me the same error. Shell is bash.

@piyushrpt
Copy link
Member

piyushrpt commented Apr 21, 2020

What version of cmake?
And are you clearing out the build folder before each cmake run? Else it will use the cached values

@jlmaurer
Copy link
Author

jlmaurer commented Apr 21, 2020

That did it...

@jlmaurer
Copy link
Author

It was using the cache. I'm feeling sheepish now. :)

@piyushrpt
Copy link
Member

All is well .... these things are never documented :-P

@jlmaurer
Copy link
Author

Thanks for the help! I'll push an update to the environment variable list at some point.

@jlmaurer
Copy link
Author

If that is helpful!

@piyushrpt
Copy link
Member

Go for it ..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants