[gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

[chris english]

Noted. And it seems this reflects the generosity of the gdal/cmake find
process, that any pertinent libs found will be included on the premise that
if one went to the effort to have them, one must want them. And when no
longer needed, remove them, which most users neglect to do at their peril;
but, they are not long sighted Maintainers.

And there are those few GDAL/OGR couplets where both must be addressed, but
if the logic is that you can't do OGR but that you have GDAL
driver...though it seems that's neither the logic nor code, they are
separate, and both will be addressed.

On Sun, Mar 6, 2022 at 1:50 PM Even Rouault <even.rouault at spatialys.com>
wrote:

>
> Le 05/03/2022 à 06:30, chris english a écrit :
>
> Kai,
> Rebuilt Geos with your insight, and two spaces between all -D entries,
> including eliminating MrSid that was complied under gcc 521 or so and might
> likely cause problems, using GDAL build hints
> <https://gdal.org/build_hints.html>, and we have success on on *target
> gcore_mdreader*, and I'll move on to sorting out what is wrong with
> missing symbols in whatever provides 'nc_open_mem', viz:
> [ 89%] Built target gcore_mdreader
> [ 89%] Linking CXX shared library libgdal.so
> /usr/bin/ld: frmts/netcdf/CMakeFiles/gdal_netCDF.dir/netcdfdataset.cpp.o:
> in function `netCDFDataset::Open(GDALOpenInfo*)':
> netcdfdataset.cpp:(.text+0x283d4): undefined reference to `nc_open_mem'
> /usr/bin/ld: netcdfdataset.cpp:(.text+0x2852a): undefined reference to
> `nc_open_mem'
>
> nc_open_mem is provided by the netCDF library. Your issue might come
> perharps from doing an initial cmake run with some netCDF version that
> includes that symbol , and re-running with an older one that hasn't it, and
> then cmake is confused becaused it has kept in cache that the netCDF lib
> has the nc_open_mem symbol. Removing CMakeCache.txt and re-running would
> solve it.
>
>
> Looks like updating libnetcdf...or perhaps not netcdf won't play nice
> with hdf5-1.12.1 till 4.9 dist release
> <https://github.com/Unidata/netcdf-c/issues/2166> so drop netcdf for now.
> And have to figure out turning off DODs, but wow, spotting a missing
> space, I'd have to perl that or something. But, have now arrived at:
>
> Which version of libdap do you use ? Note that support for DODS is likely
> to be dropped as we lack maintainers for it (see
> https://github.com/OSGeo/gdal/issues/5173)
>
>
> [ 86%] Built target gcore_mdreader
> [ 86%] Linking CXX shared library libgdal.so
> /usr/bin/ld: frmts/dods/CMakeFiles/gdal_DODS.dir/dodsdataset2.cpp.o: in
> function `get_variable(libdap::DDS&, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&)':
> dodsdataset2.cpp:(.text+0x624): undefined reference to
> `libdap::www2id(std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const&, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const&)'  <------snip
>
> and appears -DGDAL_ENABLE_DRIVER_DODS:BOOL=OFF is not doing it.
>
> That's weird... Note that there's also a OGR DODS driver, so to fully
> remove any DODS support -DOGR_ENABLE_DRIVER_DODS:BOOL=OFF would be needed
> too
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220306/ea0818fc/attachment.html>