"Fox, Shawn D (US) via gdal-dev" writes:
> I'm sure a lot of people have opinions
> about the concept of rpath vs using LD_LIBRARY_PATH. I'm not
> interested in discussing that. Our team does have a complicated
> application build and distribution process, and it isn't useful to try
> and expla
Shawn,
Without details on your build configuration, it's not going to be easy to
figure out what's up. I wouldn't spend time looking at cmake-generated
makefiles. cmake works, so if you've having issues, it's because you
haven't properly told cmake where to find things in a way that generates
the
Greg, I appreciate the reply, but this is not windows specific. The subject
line is referring to libgdal.so which would not be the library name produced on
a windows 10 system. I used powershell because I also build GDAL for Windows
and writing powershell commands allows me to write very simil
GCC 8 release notes indicate that C++17 support is still be a bit
experimental for the standard library. Anyway, can you try
https://github.com/OSGeo/gdal/pull/12231 ? I don't have access to your
compiler so I couldn't check with it, but I'd assume it should make
template deduction easier for t
Fix submitted in https://github.com/OSGeo/gdal/pull/12230
Le 30/04/2025 à 08:22, Rahkonen Jukka via gdal-dev a écrit :
Hi,
Your syntax with the "gdal" frontend is correct. This command is accepted:
gdal vector convert -f MVT --co NAME=foo in.shp out
The reason for the error may be in the com
