[PATCH] Configure GDAL.dll to not export symbols for CPLString
|Reported by:||opals||Owned by:||warmerdam|
|Severity:||normal||Keywords:||CPLString multiply defined symbols STL|
|Cc:||opals@…, Mateusz Łoskot|
Description (last modified by )
Dear all, we link to (self-built) gdal17.dll and are upgrading from MS VC8 to MS VC10. We noticed a change concerning the export of symbols for classes declared with a dll-interface (_declspec(dllexport)) that derive from a class without dll-interface, as is the case for CPLString: Both VC8 and VC10 issue a compiler warning (C4251), complaining about the base class having no dll-interface. While VC8 does not export symbols for the base class, VC10 does. CPLString derives from std::string, why symbols for std::string are exported to gdal17.dll When linking applications that instantiate std::string themselves, the linker complains about multiply defined symbols (for std::string). Of course, this can be suppressed by forcing the linker to still generate its output. However, this is a generally unsafe work-around. In the distro/public interface of GDAL, CPLString only appears in a few locations, while mostly being circumvented by usage of char*. Thus, our current work-around does not define CPLString with a dll-interface (class /*CPL_DLL*/ CPLString), and we comment out the build-option #DLLBUILD=1 (link OGR-utils to static gdal.lib; we don't use OGR functionality).
Removing CPLString completely from the distro-/dll-interface, or providing an option to not export symbols for that class would certainly be handier.
We use GDAL version 1.7.3, but the issue is the same with version 1.8. Tested on Windows Server 2008 R2 x64 SP1 and Windows 7 x64 SP1. Relates: Ticket #1647
Cheers, the OPALS-team (wk).
Change History (10)
comment:3 by , 12 years ago
|Summary:||Configure GDAL.dll to not export symbols for CPLString → [PATCH] Configure GDAL.dll to not export symbols for CPLString|