"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
