[gdal-dev] Starting a discussion on style and coding guidelines
even.rouault at spatialys.com
Thu May 5 06:26:33 PDT 2016
Le jeudi 05 mai 2016 14:22:03, Jeff McKenna a écrit :
> On 2016-05-05 9:10 AM, Jeff McKenna wrote:
> > On 2016-05-05 5:14 AM, Dmitry Baryshnikov wrote:
> >> Hi,
> >> I think it's time to go forward and shift to C++11 in i.e. GDAL 2.2 and
> >> drop old staff as it was with Windows mobile support, VB, etc.
> >> Yes, it may be some regression in ABI, but this is less evil than
> >> support lot of ancient compilers.
> >> During our work on cmake build system for GDAL I faced that some
> >> dependency library needs VC2013SP2 on Windows - i.e liblzma, as it needs
> >> C99.
> >> We worked around it by including some logic to cmake, that if VC
> >> compiler is less than specific version the support of dependent features
> >> will be disabled.
> >> By the way, the repo with cmake for GDAL is here:
> >> https://github.com/nextgis-extra/lib_gdal
> >> The ubuntu ppa of libgdal2 build using cmake:
> >> https://launchpad.net/~nextgis/+archive/ubuntu/ppa/+packages
> >> Windows builds also using cmake: http://nextgis.ru/en/borsch/
> > About a month ago I made the hard decision to upgrade my entire MS4W
> > build environment from VC 2008 to 2015. Driving this is that PHP 7 only
> > supports 2015.
> > The only GDAL dependent library not supported for VC 2015 is FileGDB
> > (I've seen an Esri developer state that 2015 SDK will be released with
> > their next FileGDB API upgrade).
> > MrSID 9.5.1 SDK works well with 2015.
> > I didn't try an ECW 5.x SDK, but the old 3.3 SDK works well with 2015.
> > Short story is I support future GDAL builds requiring a more recent
> > Visual Studio compiler (2013+), as other projects are already doing so.
> > For those packagers cringing in the thought of upgrading their whole
> > stack: join the club :)
> I should also note that for compiling Python 3.5.x VC 2015 is the
> supported environment. Yet another GDAL dependent library that favors
> an upgraded compiler on Windows.
Thanks for your feedback. Although I'd note that upgrading compiler version is
one thing, and enabling C++11 mode *might* be another, particularly if there's
a mix of C++ libs linking against each other. But from what I can read, it
seems that with Visual Studio you don't have the equivalent of -std=c++?? of
GCC, so if things are compiled with the same VS version, that should be OK.
Might be a little trickier with GCC, particularly with the new GCC 5 C++11
*ABI* and the dual ABI thing
(https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html), but if
I understand well, if people use the same GCC version and do not play with
_GLIBCXX_USE_CXX11_ABI, linking code compiled with different -std=C++?? setting
I've confirmed it with the following experiment:
$ cat a.cpp
With gcc 5.2, both
g++ -std=c++11 -fPIC -shared a.cpp -o liba.so
g++ -std=c++03 -fPIC -shared a.cpp -o liba.so
result in the following symbol to be exported:
whereas if you add -D_GLIBCXX_USE_CXX11_ABI=0, the symbol name is _Z3foov,
which is the same as if you compile with GCC 4.X
So the potential problems would be when linking a GCC 5 compiled GDAL (whether
it be C++03 or C++11) against a GCC 4.X compiled lib (think of one of the
SDK), so this might already occur currently. Or reversely, if an
application/library compiled with GCC 4.X would link against GDAL compiled
with GCC 5.X
Spatialys - Geospatial professional services
More information about the gdal-dev