Thanks for confirming that libcurl is not causing problems here.
libspatialite does have minor issues.
- It always builds with dllexport but never applies dllimport.
- 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.
I am testing libspatialite modifications now in
https://github.com/microsoft/vcpkg/pull/48834. 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.
Kai
Am 12.12.25 um 00:18 schrieb David Klaus:
All,
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.
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.
If anyone has any further questions or comments, please let me know,
On Thu, Dec 11, 2025 at 9:01 AM David Klaus <[email protected]> wrote:
Kai,
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.
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.
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,
On Thu, Dec 11, 2025 at 3:43 AM Kai Pastor, DG0YT <[email protected]>
wrote:
The proper fix is modifying libspatialite IMO.
Please confirm if there is an issue with libcurl.
I do not like to see uncertainty being made public and fixes
being made private.
Kai
Am 10.12.25 um 20:10 schrieb David Klaus:
All,
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,
On Wed, Dec 10, 2025 at 1:06 PM Kai Pastor, DG0YT via
gdal-dev <[email protected]> wrote:
In vcpkg, x64-windows means MSVC.
And even in the visibility world, you can find libs that
get it wrong when the attention is exclusively on shared
libs.
(Studying the proposed libspatialite patch, I believe I
spotted different defaults for visibility in different
chunks. Needs more investigation...)
Am 10.12.25 um 19:02 schrieb Andrew Bell:
On Wed, Dec 10, 2025 at 12:55 PM Kai Pastor, DG0YT via
gdal-dev <[email protected]> wrote:
Am 10.12.25 um 17:09 schrieb Andrew Bell via gdal-dev:
Hi,
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.
I don't think this will help with MSVC and its
dllexport declarations.
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.
This may be helpful:
https://gcc.gnu.org/wiki/Visibility
--
Andrew Bell
[email protected]
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
David Klaus
Carlson Software
*Disclaimer*
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.
--
David Klaus
Carlson Software
--
David Klaus
Carlson Software
*Disclaimer*
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.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
