The original post/current issue really points at a missing libstdc++ dev
package.
For the past build issues, it is almost never exactly "missing
libstdc++" but actually needing the C++ linker. Recognizing C++ linkage
is a problem when you cannot rely on CMake config files for static
library l
I definitely ran into build issues in that past related to missing
libstdc++ (perhaps related to using older CMake and/or clang?). But
looking closer, we only add -lstdc++ when building a test program fails
without this explicit addition. Cf
https://github.com/OSGeo/gdal/blob/master/cmake/helpe
Why does it have to force anything at all? CMake normally knows how to
setup CMAKE_CXX_IMPLICIT_LINK_LIBRARIES.
(Right now fixing hard-coded libstdc++ assumptions in ffmpeg and
dependencies in vcpkg, breaking Android.)
Kai
Am 06.07.24 um 09:59 schrieb Even Rouault via gdal-dev:
Hi,
when us
Hi,
Dear list,
I have a question about mosaicing multidimensional datasets (netCDF,
Zarr etc). These are typically 2 or 3D grids with a time dimension
from weather or ocean models (3 or 4D in total).
Using a multidimensional VRT:
https://gdal.org/drivers/raster/vrt_multidimensional.html
it
Hi,
when using CLang, GDAL forces the use of libstdc++ for linking, so
seeing "cannot find -lstdc++", I suspect you might lack the installation
of libstdc++-11-dev package
Even
Le 04/07/2024 à 08:01, Eric Knudstrup via gdal-dev a écrit :
I'm using WEBP, so the 3.4.1 release of GDAL that Ubun
