<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Thanks for confirming that libcurl is
not causing problems here.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">libspatialite does have minor issues.<br>
</div>
<div class="moz-cite-prefix">- It always builds with dllexport but
never applies dllimport.</div>
<div class="moz-cite-prefix">- The controlling macro is named
DLL_EXPORT which is not specific to the package. Reverse
dependencies following the same idea will turn on dllexport when
they include libspatialite headers.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I am testing libspatialite
modifications now in
<a class="moz-txt-link-freetext" href="https://github.com/microsoft/vcpkg/pull/48834">https://github.com/microsoft/vcpkg/pull/48834</a>. MSVC isn't a local
platform for me, and I rarely deal with nmake since GDAL moved to
CMake. So vcpkg CI building reverse dependencies is my only
indicator of success. External testing welcome.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Kai<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Am 12.12.25 um 00:18 schrieb David
Klaus:<br>
</div>
<blockquote type="cite"
cite="mid:CAJNrnBUfz+UAu2q0yJHmCpsyOxtC1S3_G7r5t-e-hKSF2ofOVQ@mail.gmail.com">
<div dir="ltr">All,
<div><br>
</div>
<div>Using a def file to obfuscate the symbol names proved to be
a bust. I was able to create obfuscated names, but that didn't
remove the original symbols from the export table. In the end,
as many have commented, the only way I could remove the
spatialite symbols from the export table was to patch the
spatialite files as seen in my custom-portfile folder.</div>
<div><br>
</div>
<div>As far as the libcurl export conflicts, this turned out to
be a red herring. The conflicting symbol was
__NULL_IMPORT_DESCRIPTOR. After a lot of searching I realized
that a dependency of the project I was building also included
my custom gdal library. To resolve this issue, I simply
removed gdal from one of my libraries. This resolved all the
conflicts I know about.</div>
<div><br>
</div>
<div>If anyone has any further questions or comments, please let
me know,</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Thu, Dec 11, 2025 at
9:01 AM David Klaus <<a href="mailto:dklaus@carlsonsw.com"
moz-do-not-send="true" class="moz-txt-link-freetext">dklaus@carlsonsw.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<div dir="ltr">Kai,
<div><br>
</div>
<div>I am still working on this issue which is why I haven't
updated the thread with a solution. I do not intend to
keep the solution private.</div>
<div><br>
</div>
<div>The libspatialite portfile I provided contains a custom
patch. I can confirm that this patch prevents export of
the libspatialite symbols that caused conflict in my
previous build. I have not attempted something similar for
libcurl. As I mentioned in my original email, I don't
particularly like this solution.</div>
<div><br>
</div>
<div>Yesterday I tried to patch in def files to the GDAL
build. I was hoping that, by removing the libspatialite
symbols from the def files export, I would be able to
prevent export of these symbols. Unfortunately, this
didn't work. Now, I am currently investigating using def
files to rename the conflicting libspatialite symbols on
export. Hopefully I have more information on this today
though it may take longer,</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Dec 11, 2025 at
3:43 AM Kai Pastor, DG0YT <<a
href="mailto:dg0yt@darc.de" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">dg0yt@darc.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<div>
<div>The proper fix is modifying libspatialite IMO.<br>
</div>
<div>Please confirm if there is an issue with libcurl.</div>
<div>I do not like to see uncertainty being made public
and fixes being made private.</div>
<div><br>
</div>
<div>Kai<br>
</div>
<div><br>
</div>
<div>Am 10.12.25 um 20:10 schrieb David Klaus:<br>
</div>
<blockquote type="cite">
<div dir="ltr">All,
<div><br>
</div>
<div>Thank you for the suggestions. And to clarify:
yes this is an MSVC build so -fvisibility=hidden
is not an option. I am currently investigating
adding a def file to curate the symbols exported
by the gdal dll. I removed the decorated symbols
and built. The resulting dll still reports the
decorated symbols, but I'm hopeful that this is
expected behavior. I'm going to attempt to remove
the libspatialite symbols from the def file and
rebuild,</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Dec 10,
2025 at 1:06 PM Kai Pastor, DG0YT via gdal-dev
<<a href="mailto:gdal-dev@lists.osgeo.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">gdal-dev@lists.osgeo.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<div>
<div>In vcpkg, x64-windows means MSVC.</div>
<div><br>
</div>
<div>And even in the visibility world, you can
find libs that get it wrong when the attention
is exclusively on shared libs.</div>
<div>(Studying the proposed libspatialite patch,
I believe I spotted different defaults for
visibility in different chunks. Needs more
investigation...)<br>
</div>
<div><br>
</div>
<div>Am 10.12.25 um 19:02 schrieb Andrew Bell:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed,
Dec 10, 2025 at 12:55 PM Kai Pastor,
DG0YT via gdal-dev <<a
href="mailto:gdal-dev@lists.osgeo.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">gdal-dev@lists.osgeo.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<div>
<div>Am 10.12.25 um 17:09 schrieb
Andrew Bell via gdal-dev:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>All symbols that aren't
specifically exported should be
hidden if when you build the
flag "-fvisibility=hidden" is
set. See
cmake/helpers/configure.cmake.</div>
</div>
</blockquote>
<p>I don't think this will help with
MSVC and its dllexport declarations.<br>
</p>
</div>
</blockquote>
<div><br>
I don't know that this is MSVC. I
thought it was a GCC build on Windows,
but regardless, things are essentially
the same (on Windows you *must* export
all the symbols you want visible). I
don't know spatialite, but there should
be some sort of DLL marker (like CPL_DLL
in GDAL) that can be turned off when
building a static library that you then
link into GDAL.<br>
<br>
This may be helpful:<br>
<br>
<a
href="https://gcc.gnu.org/wiki/Visibility" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://gcc.gnu.org/wiki/Visibility</a><br>
<br>
</div>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>Andrew Bell</div>
<a
href="mailto:andrew.bell.ia@gmail.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">andrew.bell.ia@gmail.com</a></div>
</div>
</div>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">gdal-dev@lists.osgeo.org</a><br>
<a
href="https://lists.osgeo.org/mailman/listinfo/gdal-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote>
</div>
<div><br>
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">David Klaus
<div>Carlson Software</div>
</div>
</div>
<br>
<br>
<p><b>Disclaimer</b></p>
<p>The information contained in this communication
from the sender is confidential. It is intended
solely for use by the recipient and others
authorized to receive it. If you are not the
recipient, you are hereby notified that any
disclosure, copying, distribution or taking action
in relation of the contents of this information is
strictly prohibited and may be unlawful.</p>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
</div>
<div><br>
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">David Klaus
<div>Carlson Software</div>
</div>
</div>
</blockquote>
</div>
<div><br>
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">David Klaus
<div>Carlson Software</div>
</div>
</div>
<br>
<br>
<p><b>Disclaimer</b></p>
<p>The information contained in this communication from the sender
is confidential. It is intended solely for use by the recipient
and others authorized to receive it. If you are not the
recipient, you are hereby notified that any disclosure, copying,
distribution or taking action in relation of the contents of
this information is strictly prohibited and may be unlawful.</p>
</blockquote>
<p><br>
</p>
</body>
</html>