This may already be known, but the use of std::string in CPLString
can also cause problems e.g. building a program with a version of
a C++ stdlib that differs from the one that a prebuilt GDAL DLL
used. Visual Studio e.g. has afaik a 48-byte std::string in MSVC 2010
vs. 40 bytes in MSVC 2022. It's obvious in hindsight, but it's easy
to get lulled into using an old DLL for a long time not realizing
it too must be recompiled.
Ray
On 2/25/2024 8:46 PM, Simon Eves via gdal-dev wrote:
As we're not ready to upgrade Arrow just yet, I also did the namespace
change as a pre-build code patch on the regular 3.7.3 bundle.
Apologies to Bjorn and anyone else on that team for any inference that
this was a flatbuffers bug. Not my intention. Glad we worked it out.
Simon
On Sun, Feb 25, 2024 at 5:52 PM Even Rouault <even.roua...@spatialys.com
<mailto:even.roua...@spatialys.com>> wrote:
>
> OK, so I guess we might be able to avoid it by upgrading Arrow, as
> long as that doesn't break something else. I guess you need to do
> the custom namespace thing too, though.
(ab)use of preprocessor functionality makes it easy:
https://github.com/OSGeo/gdal/pull/9313
<https://github.com/OSGeo/gdal/pull/9313> ...
>
> I hate computers.
:-) :-)
--
http://www.spatialys.com <http://www.spatialys.com>
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
