[gdal-dev] How can I avoid absolute path to shared libraries in libgdal.so

[Fox, Shawn D (US)]

Having built GDAL 3.7.0, I'm observing the following output.

# output of ldd shows the issue

ldd libgdal.so
        linux-vdso.so.1 (0x00007ffe0e3f7000)
        libdl.so.2 => /lib64/libdl.so.2
(0x00007feaca6a6000)
        libcurl.so.4 => /lib64/libcurl.so.4
(0x00007feaca417000)
        libproj.so.22 => not found
        libexpat.so.1 =>
/lib64/libexpat.so.1 (0x00007feaca1db000)
        libxerces-c-3.1.so => not found
        /data/third_party_unzip/exp/SQLite/SQLite-3.23.1/lib/libsqlite3.so
=> not found

Notice that the only absolute path is for sqlite3.  I had to specify the full path to all dependencies but only the full path to sqlite is embedded into the .so file. This is a major problem since now GDAL will not load at run-time unless libsqlite exists on the system at that exact location. I'm supplying absolute paths to the location of all dependencies in the cmake command to generate the build directory. Does anyone know why sqlite would be linked differently? So far I'm searching through the build directory for references but I haven't found a reason or the behavior yet.  The build instructions at gdal.org seem straightforward so I don't see anything on that site that explains the behavior.  I'm guessing it relates to how the build files are generated by the gdal build system. I don't want the absolute path to anything baked into libgdal.so.

My Cmake command to generate the build looks like this, and I'm also putting path to all dependencies into LD_LIBRARY_PATH first. I didn't think it would help to show all of the paths since they'd be different on other Linux systems.  Bases on this I'm failing to understand why the dependencies are not linked in consistently.  I'm building GDAL using powershell commands.

$Env:LD_LIBRARY_PATH="${CURL_LIB_DIR}:${SQLITE_LIB_DIR}:${EXPAT_LIB_DIR}:${PROJ_LIB_DIR}:${XERCES_LIB_DIR}:${OPENSSL_LIB_DIR}:${Env:LD_LIBRARY_PATH}"

cmake -S . -B ../build/$CONFIGL -DCMAKE_INSTALL_PREFIX="../install/$CONFIGL" -DCMAKE_BUILD_TYPE="$CONFIG" `
  -DGDAL_USE_OPENSSL=OFF -DGDAL_USE_EXTERNAL_LIBS:BOOL=OFF `
  -DOPENSSL_ROOT_DIR="$OPENSSL_ROOT_DIR" `
  -DPROJ_INCLUDE_DIR="$PROJ_INCLUDE" -DPROJ_LIBRARY_RELEASE="$PROJ_LIB" `
  -DGDAL_USE_CURL=ON -DCURL_INCLUDE_DIR="$CURL_INCLUDE" -DCURL_LIBRARY_RELEASE="$CURL_LIB" `
  -DGDAL_USE_XERCESC=ON -DXercesC_INCLUDE_DIR="$XERCES_INCLUDE" -DXercesC_LIBRARY="$XERCES_LIB" `
  -DGDAL_USE_EXPAT=ON -DEXPAT_INCLUDE_DIR="$EXPAT_INCLUDE" -DEXPAT_LIBRARY="$EXPAT_LIB" `
  -DGDAL_USE_SQLITE3=ON -DSQLite3_INCLUDE_DIR="$SQLITE_INCLUDE" -DSQLite3_LIBRARY="$SQLITE_LIB" `
  -DACCEPT_MISSING_SQLITE3_MUTEX_ALLOC:BOOL=ON -DACCEPT_MISSING_SQLITE3_RTREE:BOOL=ON `
  2>&1 | tee cmake_configure_${PLATFORM}_${TOOLSET}_${CONFIGL}.txt

Thanks,

Shawn Fox
Sr Principal SW Engineer
BAE Systems, Inc.
Geospatial eXploitation Products
T: 858-592-5310 office phone number | M: 858-337-2380 | E: shawn.fox at baesystems.com
10920 Technology Pl, San Diego, CA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250429/7cce7ccf/attachment.htm>