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 linkage. The library which needs C++ linkage can be behind a
library with C interface, and subject to configuration.
Example: lerc behind tiff.
(In vpckg ports, I add the difference of
CMAKE_CXX_IMPLICIT_LINK_LIBRARIES and CMAKE_C_IMPLICIT_LINK_LIBRARIES to
the pkg-config file when I need to pass on C++ linkage. Resolving it at
the root. But I know a lot of ugly hacks downstream...)
Am 06.07.24 um 12:39 schrieb Even Rouault:
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/helpers/GdalCompilationFlags.cmake#L165
to L183
Le 06/07/2024 à 12:02, Kai Pastor, DG0YT via gdal-dev a écrit :
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 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
_______________________________________________
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
