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

Wed Apr 30 11:59:16 PDT 2025

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 library in a way that you're happy with. In general, if your
dependencies are in some common location, you can just set
CMAKE_PREFIX_PATH to that location to tell cmake where to find things, but
if your dependencies are in various places on the system, you may need to
add multiple directories or, as your doing, specify each separately. I
would advise against using LD_LIBRARY_PATH since it's outside the cmake
configuration process (I think).

That said, you can use a tool like `patchelf` to modify the DT_NEEDED
entries of a library in any way you like.

Best,

On Wed, Apr 30, 2025 at 1:43 PM Fox, Shawn D (US) via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> 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
> similar commands across platforms. This problem I've described is only
> happening on the Linux platform using Red Hat Enterprise Linux version 8.
> 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 explain that.  The only thing that really matters is that
> I have to build libgdal.so with no absolute paths to any dependency baked
> into libgdal.so, and I'm asking  for some help to accomplish that with this
> new cmake build system.  So far I haven't found anything at gdal.org that
> helps to explain the behavior I'm obser
>  ving, and the generated build files are awfully difficult to read. So if
> anyone has had similar issues since the build system changed to cmake or
> has any advice on how to read through the generated build files to find the
> commands being used for linking I'd appreciate any tips. At this point I'm
> using grep on the build output to search for clues, and I haven't found any
> yet.
>
> Evidently, the -DSQLite3_LIBRARY="$SQLITE_LIB" has to have the full path
> to the library file in the variable, otherwise a build failure occurs.  Yet
> if I put the full path into it as required then the GDAL build system bakes
> it into libgdal.so.  That behavior does not occur for any other dependency.
> My guess is that the build system is generating the dash upper and lower
> case linker options differently for sqlite but I can't figure out why or
> what I need to do to manipulate it to generate what I need.
>
> I set up the cmake commands using examples from the website and then read
> the build instructions to set the paths to all dependencies that I need
> just as the instructions state that I should. According to it, there are
> specific variables for each plugin that have to be set in the cmake command
> to generate the build system so my cmake command sare modeled with those
> instructions.
> https://gdal.org/en/stable/development/building_from_source.html
>
> The GDAL build will not succeed for me on RHEL8 without specifying all of
> the library paths within LD_LIBRARY_PATH, and that is in addition to
> putting the full path into all of the variables used in the first cmake
> command to generate the build system.  It seems to be necessary in order
> for the linking to succeed.
>
> Thanks
>
> -----Original Message-----
> From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> On Behalf Of Greg
> Troxel via gdal-dev
> Sent: Tuesday, April 29, 2025 4:23 PM
> To: Fox, Shawn D (US) via gdal-dev <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] How can I avoid absolute path to shared libraries
> in libgdal.so
>
> 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.
>
>
> "Fox, Shawn D (US) via gdal-dev" <gdal-dev at lists.osgeo.org> writes:
>
> > 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
>
> [incorrect line wrapping fixed]
>
> I am puzzled by your approach and problems.   Normally you would either
> expect
>
>   dependencies to be provided by a packaging system (such as a
>   "distribution"), and then expect to have to have that set of packages
>   installed, resulting in the same files at the same paths
>
> or
>
>   construct your own packaging where you build those deps first and then
>   gdal, to some prefix
>
>
> but it seems like you have built gdal on one system and are trying to run
> it on a system with different contents.
>
> > Notice that the only absolute path is for sqlite3.  I had to specify
>
> That is odd.  I'd expect that this is the result of
>
>   -l/data/third_party_unzip/exp/SQLite/SQLite-3.23.1/lib/libsqlite3.so
>
> being passed tot he linker.
>
> > 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.
>
> Generally one needs -L and -R for the dirs that have the libs, and -l for
> libnames.
>
> > 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}"
>
> I don't think it's good to use LD_LIBRARY_PATH.  That's working around
> -L/-R not being correct.
>
> > 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
>
> I find that cmake tends to hide the actual build lines by default, and
> that one needs to remediate this with some kind of verbose option, and then
> you can see what the values of cmake variables are and what the actual
> compiler/linker flags are.
>
> It could be that you are running into Windows-specific trouble, about
> which I know very little.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250430/a0a849a6/attachment-0001.htm>