Re: [gdal-dev] [External] : Re: Python binding installation on windows

It turned out that I didn’t specify swig_executable and an old version of swig was used on linux build. After fixing this, the warning was gone. Back on windows build, with swig 4.2.1, python 3.12.2, setuptools 69.2, cmake still couldn’t install python binding. And I have to manually invoke

Re: [gdal-dev] [External] : Re: Python binding installation on windows

After upgrading setuptools, the installation on windows worked. Just curious that why “GDAL-3.8.4-py3.6.egg-info” is created under the site-packages on windows, while I set up the PYTHON_ROOT to use python 3.12 and clean up the build directory to rebuild everything. On the other hand, on

Re: [gdal-dev] [External] : Re: Python binding installation on windows

Thanks for the suggestion. I can upgrade the setuptools and try again. Another question: is it possible to only build a specific driver plugin without rebuilding the GDAL? From: Even Rouault Date: Tuesday, March 19, 2024 at 4:44 PM To: Fengting Chen , gdal-dev@lists.osgeo.org Subject: Re:

Re: [gdal-dev] [External] : Re: Python binding installation on windows

To: Fengting Chen , gdal-dev@lists.osgeo.org Subject: [External] : Re: [gdal-dev] Python binding installation on windows Hi, Le 19/03/2024 à 20:14, Fengting Chen via gdal-dev a écrit : Hi, I was able to build the GDAL with python binding on without error on windows. However, “cmake --build

[gdal-dev] Python binding installation on windows

Hi, I was able to build the GDAL with python binding on without error on windows. However, “cmake --build . --target install --config Release” command doesn’t install the python site-packages etc to the specified “CMAKE_INSTALL_PREFIX” directory. The rest of the GDAL components were installed

Re: [gdal-dev] FW: [External] : GDAL 3.8.4 build on windows failed at linking

t: Re: [gdal-dev] FW: [External] : GDAL 3.8.4 build on windows failed at linking Not the answer you'll probably want to hear, but: - Use an up-to-date compiler - Use package distributions like vcpkg or conda-forge that already brings all the dependencies "for free" - It seems you mix buil

Re: [gdal-dev] FW: [External] : GDAL 3.8.4 build on windows failed at linking

Not the answer you'll probably want to hear, but: - Use an up-to-date compiler - Use package distributions like vcpkg or conda-forge that already brings all the dependencies "for free" - It seems you mix builds of different compilers (VS vs mingw). That's a bit asking for troubles

Re: [gdal-dev] FW: [External] : GDAL 3.8.4 build on windows failed at linking

bles ;-) Le 12/03/2024 à 17:48, Fengting Chen via gdal-dev a écrit : Resend with more information: I am trying to build GDAL 3.8.4 on windows under VS2015. The build failed at linking stage that a bunch of external symbols not found, specifically the symbols in libproj, libcurl. I checked the dll

[gdal-dev] FW: [External] : GDAL 3.8.4 build on windows failed at linking

” and found the symbols in the library a little different, for example the linker error shows “__imp__curl_slist_append” not found, the symbol output from the “dumpbin” is “__imp_curl_slist_append” . Any idea how to fix this? Thanks! From: gdal-dev on behalf of Fengting Chen via gdal-dev Date

[gdal-dev] GDAL 3.8.4 build on windows failed at linking

GDAL 3.8.4 build on Windows from VS2015 x64 command prompt: “cmake –build .” throws the following error (there are more similar errors): cpl_vsil_az.obj : error LNK2001: unresolved external symbol __imp__curl_slist_append [E:\gdal-3.8.4\build\GDAL.vcxproj] cmake options has: set

Re: [gdal-dev] [External] : Re: GDAL build on windows failed for FILEGDB driver

Thanks, that is clear now. One more question, anywhere to get proj_9_3.lib and sqlite3 .lib, most downloadable package only has .dll. From: Even Rouault Date: Saturday, March 2, 2024 at 1:50 PM To: Fengting Chen , gdal-dev@lists.osgeo.org Subject: Re: [External] : Re: [gdal-dev] GDAL build

Re: [gdal-dev] [External] : Re: GDAL build on windows failed for FILEGDB driver

That is what I guessed. But the documentation says: CURL_LIBRARY_RELEASE• Path to a shared or static library file, such as libcurl.dll, libcurl.so, libcurl.lib, or other name. If I use .lib here, will GDAL

Re: [gdal-dev] [External] : Re: GDAL build on windows failed for FILEGDB driver

en Rouault Date: Friday, March 1, 2024 at 5:54 PM To: Fengting Chen , gdal-dev@lists.osgeo.org Subject: [External] : Re: [gdal-dev] GDAL build on windows failed for FILEGDB driver Le 01/03/2024 à 20:31, Fengting Chen via gdal-dev a écrit : Hi, I am using VS2015 terminal and cmake to build GDAL

[gdal-dev] GDAL build on windows failed for FILEGDB driver

Hi, I am using VS2015 terminal and cmake to build GDAL on windows. I got the following compilation error for filegdbindex_write.cpp. Any idea? E:\gdal-3.8.4\ogr\ogrsf_frmts\openfilegdb\filegdbindex_write.cpp(1388): note: while trying to match the argument list

Re: [gdal-dev] [External] : Re: GDAL driver Open() calls

Hi Even, Here is what found out from debugging: There are two Open() calls. Your fix skipped one. Here is the stack trace of the second one: [cid:image001.png@01DA239D.5F51E090] Thanks! From: Even Rouault Date: Thursday, November 30, 2023 at 8:40 AM Le 30/11/2023 à 04:47, Fengting Chen a

Re: [gdal-dev] [External] : Re: GDAL driver Open() calls

com> Date: Tuesday, November 28, 2023 at 6:36 PM Hi, Please share the stack trace (on a debug build) of both instances where GDALOpen() is called Even Le 28/11/2023 à 23:40, Fengting Chen via gdal-dev a écrit : Hi, I noticed from the GeoRaster driver that in GDAL 3.6 and 3.7 (m

Re: [gdal-dev] [External] : Re: GDAL driver Open() calls

: Tuesday, November 28, 2023 at 6:36 PM To: Fengting Chen , gdal-dev@lists.osgeo.org Subject: [External] : Re: [gdal-dev] GDAL driver Open() calls Hi, Please share the stack trace (on a debug build) of both instances where GDALOpen() is called Even Le 28/11/2023 à 23:40, Fengting Chen via gdal-dev

[gdal-dev] GDAL driver Open() calls

Hi, I noticed from the GeoRaster driver that in GDAL 3.6 and 3.7 (maybe 3.8 too), there are two GDALOpen() calls on the driver with GDALOpenInfo eAccess as GA_ReadOnly, even when the GeoRaster is the output format in gdal_translate command. There are no such calls in GDAL 3.4. I am wondering