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. I thought I’d share the details of how I fixed the issue for my situation in case it will help someone else in the future who searches the archives.
Try this to test whether you are having a similar problem. This was done on my rebuilt libsqlite3 library and the attribute is present as it should be. If it is missing in yours then that could cause the problem. 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’ve no idea why that issue with the libsqlite3 library would affect the cmake build of gdal, but it did. Thanks, Shawn Fox From: Andrew Bell <andrew.bell...@gmail.com> Sent: Wednesday, April 30, 2025 11:59 AM To: Fox, Shawn D (US) <shawn....@baesystems.us> Cc: gdal-dev@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. 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@lists.osgeo.org<mailto:gdal-dev@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<http://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-boun...@lists.osgeo.org<mailto:gdal-dev-boun...@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@lists.osgeo.org<mailto:gdal-dev@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@lists.osgeo.org<mailto:gdal-dev@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<http://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<http://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@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<mailto:gdal-dev@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Andrew Bell andrew.bell...@gmail.com<mailto:andrew.bell...@gmail.com>
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
