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

[David Klaus]

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

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/20251211/abede89f/attachment.htm>