[gdal-dev] [External] : Re: libgdal.so.36 refers to sqlite library with full path

[Fox, Shawn D (US)]

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-bounces at lists.osgeo.org> On Behalf Of Andrew Bell via gdal-dev
Sent: Wednesday, May 14, 2025 3:47 PM
To: Fengting Chen <fengting.chen at oracle.com>
Cc: gdal-dev <gdal-dev at 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.ia at gmail.com<mailto:andrew.bell.ia at gmail.com>

On Wed, May 14, 2025, 6:10 PM Fengting Chen via gdal-dev <gdal-dev at lists.osgeo.org<mailto:gdal-dev at 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.rouault at spatialys.com<mailto:even.rouault at spatialys.com>>
Date: Wednesday, May 14, 2025 at 5:04 PM
To: Fengting Chen <fengting.chen at oracle.com<mailto:fengting.chen at oracle.com>>, gdal-dev <gdal-dev at lists.osgeo.org<mailto:gdal-dev at 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 at lists.osgeo.org<mailto:gdal-dev at 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 at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250515/27b4576e/attachment-0001.htm>