<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Am 10.12.25 um 16:36 schrieb David
Klaus via gdal-dev:<br>
</div>
<blockquote type="cite"
cite="mid:CAJNrnBWrSgg2FaeZo2CSMSLcj=iumUs28KuuOiqQC05wXeXaLw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div>My company produces a custom GDAL build using vcpkg. GDAL
itself is built as a DLL, while all of its dependencies are
built as static libraries and linked into GDAL. To support
this, I created a custom triplet --
x64-windows-mixed-carlson-gdal.cmake -- included in the
attached custom-triplets folder.<br>
<br>
The resulting GDAL DLL works, but it exposes an unintended
side effect: symbols from some static dependencies—for
example, libspatialite and libcurl—are being exported from
the GDAL DLL. This becomes a problem because the environment
where our GDAL build runs also loads its own custom builds
of these libraries, and the exported symbols conflict with
those versions.<br>
</div>
</div>
</div>
</blockquote>
<p>I have this seen this in vpckg for other libraries, and it can be
fixed. </p>
<p>However, I would be surprised if it really occurs for libcurl.</p>
<blockquote type="cite"
cite="mid:CAJNrnBWrSgg2FaeZo2CSMSLcj=iumUs28KuuOiqQC05wXeXaLw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div>So far, I have mitigated this for libspatialite by adding
a patch -- cs_ensure_no_dll_export.patch -- in its portfile
to disable symbol export by overriding defines in various
libspatialite headers. However, this approach is not ideal
because:<br>
<br>
1. It requires maintaining patches for every conflicting
library indefinitely, adding ongoing development overhead.<br>
2. The solution is brittle; updates to any patched library
may break the build.<br>
<br>
To me this seems like a fairly common use case, but our
environment is unique. So, perhaps others don't need a build
of GDAL that links it's dependencies statically. In any
case, I would appreciate any guidance on how to prevent
symbol exports from GDAL’s statically linked dependencies in
a more robust, maintainable way.</div>
</div>
</div>
</blockquote>
<p>You get a robust solution by upstreaming. At least to vcpkg,
better to each actual source (libspatialite etc.). GDAL can't fix
anything about careless dllexport in its dependencies.<br>
</p>
<p>Kai<br>
vcpkg contributor<br>
</p>
</body>
</html>