I reported the same problem recently, but I determined in my case that the problem was my build of libsqlite3 which for some reason was missing the SONAME attribute from the binary. This had the effect of the CMAKE build of GDAL containing the absolute path of libsqlite3 in the libgdal.so file.
Try this to test whether you are having a similar problem. This was done on my rebuilt libsqlite3 library and the attribute is present. If it is missing in yours then that could cause the problem. I’m not exactly sure why, but troubleshooting the cmake build is awfully difficult. objdump -p libsqlite3.so | grep SONAME SONAME libsqlite3.so.0 To fix it, I rebuilt my libsqlite3 binary, but you could patch that file to add in the attribute or rebuild it with the correct compiler options to create the attribute. You could also patch the gdal library after the build. To use patchelf to add a SONAME. ‘patchelf --set-soname libsqlite3.so.3 libsqlite3.so’ The line in my Makefile for RHEL8 to build it with the soname looks like this, $(CC) $(CFLAGS) -shared sqlite3.o -Wl,-soname,libsqlite3.so.0 -o $(LIBS)/libsqlite3.so After doing that and rebuilding GDAL the libgdal.so file was as I expected with no absolute path to libsqlite3.so. I preferred to fix the root cause and stored the corrected libsqlite3 binary in our local repository so that I don’t have to keep patching libgdal after every build. ldd libgdal.so | grep libsqlite3 libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007fcdab1d7000) I hope that helps you. That is how I solved the same kind of problem in my case while building GDAL 3.7.0. Thanks, Shawn Fox From: gdal-dev <gdal-dev-boun...@lists.osgeo.org> On Behalf Of Andrew Bell via gdal-dev Sent: Wednesday, May 14, 2025 3:47 PM To: Fengting Chen <fengting.c...@oracle.com> Cc: gdal-dev <gdal-dev@lists.osgeo.org> Subject: Re: [gdal-dev] [External] : Re: libgdal.so.36 refers to sqlite library with full path External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar. You can use patchelf or a similar program to modify dependencies. -- Andrew Bell andrew.bell...@gmail.com<mailto:andrew.bell...@gmail.com> On Wed, May 14, 2025, 6:10 PM Fengting Chen via gdal-dev <gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>> wrote: Both GDAL and PROJ refer to my custom build sqlite3 library. The sqlite3 entry in PROJ library looks normal, that is, just the library name without path. My concern is that libgdal.so has libsqlite3.so with full path. How could this happen? How do I remove this? From: Even Rouault <even.roua...@spatialys.com<mailto:even.roua...@spatialys.com>> Date: Wednesday, May 14, 2025 at 5:04 PM To: Fengting Chen <fengting.c...@oracle.com<mailto:fengting.c...@oracle.com>>, gdal-dev <gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>> Subject: [External] : Re: [gdal-dev] libgdal.so.36 refers to sqlite library with full path Maybe another library that GDAL is depending on is linked against the system sqlite3 and not your custom build ? That could be PROJ typically Le 14/05/2025 à 22:58, Fengting Chen via gdal-dev a écrit : Hi, I am trying to build GDAL 3.10.3 with sqlite 3.49.2. The build was successful on linux. But there are two entries of reference to sqlite3, and one of it has the absolution path. > ldd libgdal.so.36 | grep sqlite ldd: warning: you do not have execution permission for `./libgdal.so.36' /scratch/gdal_dir/SDK/sqlite/3.49.2/dist/lib/libsqlite3.so (0x00007f7e08168000) libsqlite3.so => / scratch/gdal_dir/SDK/sqlite/3.49.2/dist/lib/libsqlite3.so (0x00007f7dfb00e000) Why is above listing having a full path of libsqlite3.so built in the libgdal.so.36? The configuration for the cmake for GDAL is: set (SQLite3_INCLUDE_DIR "$(SQLITE3_DIST_DIR)/ include" CACHE PATH "" FORCE) set (SQLite3_LIBRARY "$(SQLITE3_DIST_DIR)/lib/ $(LIBSQLITE3)" CACHE PATH "" FORCE) At the sqlite lib directory, it has: libsqlite3.a libsqlite3.so.0@ pkgconfig/ libsqlite3.so@ libsqlite3.so.3.49.2* Is this sqlite3 build issue or GDAL build issue? Thanks. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/gdal-dev<https://urldefense.com/v3/__https:/lists.osgeo.org/mailman/listinfo/gdal-dev__;!!ACWV5N9M2RV99hQ!IYTAe90PeRIf_wj9IWwRo5D25Ll_Dqjy6ZUwhS1joyPnRj0waH4uKmjh0GN2-UVNert2VyP1mnq_6fU7q1t4i14PHNK2$> -- http://www.spatialys.com<https://urldefense.com/v3/__http:/www.spatialys.com__;!!ACWV5N9M2RV99hQ!IYTAe90PeRIf_wj9IWwRo5D25Ll_Dqjy6ZUwhS1joyPnRj0waH4uKmjh0GN2-UVNert2VyP1mnq_6fU7q1t4i4kI3dZu$> My software is free, but my time generally not. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org<mailto: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
