Closed nilsnolde closed 7 months ago
@nilsnolde Please edit the issue content to something meaningful
yeah sorry, still writing, that was a glitch on my keyboard!
sorry, was researching on the side, was a bit confused for a few mins :D
The official upstream installation is in ${CMAKE_INSTALL_INCLUDEDIR}. Some distributions like Debian change it : https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules?ref_type=heads#L56 Changing to ${CMAKE_INSTALL_INCLUDEDIR}/gdal might be something for an hypothetical GDAL 4.0
Yeah I saw the Debian recipe. So the only way today is to hack the CFlags to get a -I /usr/include/gdal
for distros which change the dir? We're using CMake's pkg_check_modules
to find GDAL (personally I prefer that stuff with the package installation and not CMake versioned), so it seems the .pc file doesn't advertise /usr/include/gdal
as include dir and thus a #include <gdal_priv.h>
fails. Or can I rely on CONFIG mode for CMake? Or any other thing you'd recommend to get package manager independent behavior?
I would expect using find_package(GDAL CONFIG)
and the GDAL::GDAL
target to do the right thing.
so it seems the .pc file doesn't advertise /usr/include/gdal
I don't confirm this. Doing cmake .. -DCMAKE_INSTALL_INCLUDEDIR=include/gdal
generates a gdal.pc with:
CONFIG_VERSION=3.9.0dev
CONFIG_INST_PREFIX=/usr/local
CONFIG_INST_LIBS=-L/usr/local/lib -lgdal
CONFIG_INST_CFLAGS=-I/usr/local/include/gdal
CONFIG_INST_DATA=/usr/local/share/gdal
prefix=${CONFIG_INST_PREFIX}
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${exec_prefix}/include/gdal
datadir=${CONFIG_INST_DATA}
Name: libgdal
Description: Geospatial Data Abstraction Library
Version: ${CONFIG_VERSION}
Libs: ${CONFIG_INST_LIBS}
Libs.private: -larchive -lodbcinst -lcryptopp -lssl -lcrypto -llzma -ldeflate -llz4 -larmadillo -lOpenCL -lqhull_r -lgeotiff -ltiff -lheif -lzstd -laec -ljpeg -lpoppler -lpodofo -lpng -lgif -lnetcdf -lblosc -lcfitsio -L/usr/lib/x86_64-linux-gnu/hdf5/serial -lhdf5 -lsz -ldl -lwebp -ldfalt -lmfhdfalt -lopenjp2 -lIlmImf -lIlmImfUtil -lHalf -lIex -lkmlbase -lkmldom -lkmlengine -lminizip -luriparser -lz -lfyba -lfygm -lfyut -lpcre2-8 -lspatialite -lsqlite3 -lxerces-c -lmysqlclient -lpq /opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.10.so.5.1 -lodbc -lfreexl -logdi -lexpat -lxml2 -lgeos_c -lcurl -lproj -ljson-c -lpthread -lstdc++ -lm
Cflags: ${CONFIG_INST_CFLAGS}
huh weird.. I'll spin up a ubuntu container and have a look, that's where our CI fails. thanks for the quick investigation!
jep, installing libgdal-dev
on ubuntu 23.04 produces a wrong .pc file:
cat /usr/lib/x86_64-linux-gnu/pkgconfig/gdal.pc
CONFIG_VERSION=3.6.2
CONFIG_INST_PREFIX=/usr
CONFIG_INST_LIBS=-L/usr/lib/x86_64-linux-gnu -lgdal
CONFIG_INST_CFLAGS=-I/usr/include/gdal
CONFIG_INST_DATA=/usr/share/gdal
prefix=${CONFIG_INST_PREFIX}
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${exec_prefix}/include <--- should be ${exec_prefix}/include/gdal
datadir=${CONFIG_INST_DATA}
Name: libgdal
Description: Geospatial Data Abstraction Library
Version: ${CONFIG_VERSION}
Libs: ${CONFIG_INST_LIBS}
Libs.private: -lodbcinst -lssl -llzma -ldeflate -llz4 -larmadillo -lqhull_r -lgeotiff -ltiff -lheif -lzstd -ljpeg -lpoppler -lpng -lgif -lnetcdf -L/usr/lib/x86_64-linux-gnu/hdf5/serial -lhdf5_hl -lblosc -lcfitsio -lhdf5 -lcrypto -lpthread -lsz -ldl -lcurl -lwebp -ldfalt -lmfhdfalt -lopenjp2 -lkmlbase -lkmldom -lkmlengine -lminizip -luriparser -lz -lfyba -lfygm -lfyut -lpcre2-8 -lspatialite -lsqlite3 -lxerces-c -lmysqlclient -lpq -lodbc -lfreexl -logdi -lexpat -lxml2 -lgeos_c -lproj -ljson-c -lstdc++ -lm
Cflags: ${CONFIG_INST_CFLAGS}
I'll close here as it's an ubuntu packaging issue..
I'll close here as it's an ubuntu packaging issue..
Actually this was a GDAL issue which got fixed in 9579d8d0ffb84c8c2ade5b24de90b1c1f191aef5 in GDAL 3.8.0
uh, ok, thanks, was just about to flag it to ubuntu. we'll use cmake for the time being
Expected behavior and actual behavior.
I'd expect GDAL headers to be installed to
<prefix>/include/gdal
for cmake based installations.Steps to reproduce the problem.
do a cmake build and a
cmake --install build
Operating system
any
GDAL version and provenance
in fact debian-based and fedora/OpenSUSE seem to install from their package managers to
usr/include/gdal
, but my local manjaro doesn't. neither do vcpkg & brew distributions of gdal which seem to use the cmake installation as is.tbh, it's also cluttering up the include dir quite a bit :smile:
CI for our recent addition of gdal into valhalla (for isochrones as geotiff) is a little confused as to where
#include <gdal_priv.h>
from: https://github.com/valhalla/valhalla/pull/4594. and I do wonder how other programs do it when they include gdal headers, e.g. QGIS includes withoutgdal/
. is everyone adding custom include search paths for debian/fedora/others? or is it just late at night and I'm blind?