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-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> 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> 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@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
