[gdal-dev] Preventing symbol export in custom GDAL build
Kai Pastor, DG0YT
dg0yt at darc.de
Fri Dec 12 00:03:21 PST 2025
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 <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
>>>
>>> --
>>> 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
>>
>>
>>
>> --
>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251212/54b37304/attachment.htm>
More information about the gdal-dev
mailing list