[gdal-dev] Preventing symbol export in custom GDAL build

Fri Dec 12 05:35:52 PST 2025

Kai,

Thank you for that information. In regards to your fix for this issue. Are
these changes coming to libspatialite in vcpkg in the future?

On Fri, Dec 12, 2025 at 3:03 AM Kai Pastor, DG0YT <dg0yt at darc.de> wrote:

> 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
> <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 <dklaus at carlsonsw.com> 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 <dg0yt at darc.de> 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 <
>>> gdal-dev at lists.osgeo.org> 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 <
>>>> gdal-dev at lists.osgeo.org> 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
>>>> <https://gcc.gnu.org/wiki/Visibility>
>>>>
>>>> --
>>>> Andrew Bell
>>>> andrew.bell.ia at gmail.com
>>>>
>>>>
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>> <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.
>
>
>

-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251212/c3faf133/attachment-0001.htm>