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 l
"Fox, Shawn D (US) via gdal-dev" writes:
> 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 expla
r
> for the linking to succeed.
>
> Thanks
>
> -Original Message-
> From: gdal-dev On Behalf Of Greg
> Troxel via gdal-dev
> Sent: Tuesday, April 29, 2025 4:23 PM
> To: Fox, Shawn D (US) via gdal-dev
> Subject: Re: [gdal-dev] How can I avoid absolute path t
s to be necessary in order for the linking to
succeed.
Thanks
-Original Message-
From: gdal-dev On Behalf Of Greg Troxel via
gdal-dev
Sent: Tuesday, April 29, 2025 4:23 PM
To: Fox, Shawn D (US) via gdal-dev
Subject: Re: [gdal-dev] How can I avoid absolute path to shared libraries in
l
"Fox, Shawn D (US) via gdal-dev" writes:
> ldd libgdal.so
> linux-vdso.so.1 (0x7ffe0e3f7000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7feaca6a6000)
> libcurl.so.4 => /lib64/libcurl.so.4 (0x7feaca417000)
> libproj.so.22 => not found
> libexpat.so.1 =
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 (0x7ffe0e3f7000)
libdl.so.2 => /lib64/libdl.so.2
(0x7feaca6a6000)
libcurl.so.4 => /lib64/libcurl.so.4
(0x7feaca417000)
libproj.so
