[gdal-dev] Antwort: Re: Build static GDAL-Lib and static GDAL-Apps

[Kai Pastor, DG0YT]

Am 13.02.24 um 08:18 schrieb Michael Otto via gdal-dev:
> I currently use an Ubuntu VM and use an Alpine-Linux Docker container 
> for compiling. First a static Geos library is created via cmake, then 
> a static Proj library (without Curl, because this currently leads to 
> errors) and then Gdal as a static library.

You must consider all transitive dependencies, build them in the right 
order, and ensure that transitive link libraries are passed on down to 
gdal and to the final app (with link libraries in correct order).
For more than a minimal build, it is really better solved by using 
package managers such as vcpkg than by reinventing the wheel - each 
dependency may add its own set of problems. A simplified(!) dependency 
graph for a minimal build in vcpkg, just gdal core features + geos:

zlib:
libjpeg-turbo:
liblzma:
openssl:
nlohmann-json:
curl[openssl, ssl, non-http]: openssl, zlib
sqlite3[json1, tool]:
tiff[lzma, jpeg, zip]: libjpeg-turbo, liblzma, zlib
proj[tiff, net]: curl, nlohmann-json, sqlite3, tiff
libgeotiff: proj, tiff
json-c:
geos:
gdal: geos, json-c, libgeotiff, proj, tiff, zlib

So libgeotiff, proj, tiff, curl all come with transitive usage 
requirements which depend on actual configuration.
This is impossible to reconstruct in CMake find modules (coming with 
CMake or GDAL).
In vcpkg, ports (maintainers) ensure that usage requirements are 
exported by each package (using CMake config or find module wrappers).

Kai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240214/d26d93f1/attachment.htm>