On samedi 21 avril 2018 20:46:51 CEST Sebastiaan Couwenberg wrote: > On 04/21/2018 08:15 PM, Even Rouault wrote: > > On samedi 21 avril 2018 19:58:42 CEST Sebastiaan Couwenberg wrote: > >> On 04/21/2018 07:53 PM, Even Rouault wrote: > >>> On samedi 21 avril 2018 19:32:23 CEST Sebastiaan Couwenberg wrote: > >>>> Hi Even, > >>>> > >>>> Regarding the C++11 requirement, this causes the liblas build to fail > >>>> due to the check in cpl_port.h. > >>>> > >>>> liblas uses -std=c++98 whereas the gdal build used -std=gnu89 > >>> > >>> You mean GDAL uses -std=c++11 right ? > >> > >> No, the build used -std=gnu89, see the attached build log. > > > > Ah, std=gnu89 is used only to compiled .c files (to make sure we don't use > > a higher C dialect, that wouldn't be supported by MSVC) > > But C++ files are compiled without any -std= since presumably the compiler > > you use on debian unstable defaults to C++14 > > > >>>> . Do you > >>>> recommend the latter for projects that depend on GDAL? Or should they > >>>> prefer -std=c++11? > >>> > >>> Projects using GDAL C++ API should use at least -std=c++11 (or higher) > >> > >> See my previous message in this thread. Just changing -std=c++98 to > >> -std=c++11 did not fix the liblas build failure. > > > > Hum weird. I've just managed to build libLAS 1.8.1 against GDAL 2.3.0, > > with cmake, by forcing CMAKE_CXX_FLAGS_RELEASE= -O3 -DNDEBUG -std=c++11, > > with the gcc 5.4 of my ubuntu 16.04 > > > > Actually I see in the log that -ansi is used, and according to gcc > > manpage, -ansi in C++ mode is equivalent to -std=c++98. So perhaps -ansi > > -std=c++11 is equivalent to -ansi. > Removing -ansi doesn't trigger the error in cpl_port.h, but the build > still fail on Debian unstable: > > /build/liblas-1.8.1/src/gt_citation.cpp: In function 'void > SetGeogCSCitation(GTIF*, OGRSpatialReference*, char*, int, short int)': > /build/liblas-1.8.1/src/gt_citation.cpp:390:58: error: call of > overloaded 'GetPrimeMeridian(NULL)' is ambiguous > double primemValue = poSRS->GetPrimeMeridian(NULL); > ^
Ah, must be due to having a GetPrimeMeridian(char** = nullptr) and GetPrimeMeridian(const char**) now in GDAL 2.3.0. I added also a GetPrimeMeridian(std::nullptr_t), but NULL is not nullptr... Can be fixed by just using poSRS->GetPrimeMeridan() -- Spatialys - Geospatial professional services http://www.spatialys.com
