<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Am 13.02.24 um 08:18 schrieb Michael
Otto via gdal-dev:<br>
</div>
<blockquote type="cite"
cite="mid:OFAE0B81C2.ED89AD5C-ONC1258AC2.00243F7A-C1258AC2.00281B89@data-experts.de"><span>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. </span><br>
</blockquote>
<p>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).<br>
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:</p>
<p>zlib:<br>
libjpeg-turbo:<br>
liblzma:<br>
openssl:<br>
nlohmann-json:<br>
curl[openssl, ssl, non-http]: openssl, zlib<br>
sqlite3[json1, tool]:<br>
tiff[lzma, jpeg, zip]: libjpeg-turbo, liblzma, zlib<br>
proj[tiff, net]: curl, nlohmann-json, sqlite3, tiff<br>
libgeotiff: proj, tiff<br>
json-c:<br>
geos:<br>
gdal: geos, json-c, libgeotiff, proj, tiff, zlib<br>
</p>
<p>So libgeotiff, proj, tiff, curl all come with transitive usage
requirements which depend on actual configuration.<br>
This is impossible to reconstruct in CMake find modules (coming
with CMake or GDAL).<br>
In vcpkg, ports (maintainers) ensure that usage requirements are
exported by each package (using CMake config or find module
wrappers).<br>
</p>
<p>Kai<br>
</p>
</body>
</html>