<div dir="ltr">Without comment on whether any way is correct - I believe this is the definitive source for how CMAKE approaches the subject :<br><br><a href="https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling">https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling</a><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 4 Jul 2022 at 13:47, Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> writes:<br>
<br>
> Le 04/07/2022 à 07:32, Brad Hards a écrit :<br>
>> On Monday, 4 July 2022 3:19:55 PM AEST Nik Sands wrote:<br>
>>> Is it expected that these GDAL utilities (such as gdalinfo) would look for<br>
>>> GDAL in /usr/lib instead of the location in which it was actually built?<br>
>> No.<br>
>><br>
>> I think your conceptual problem is expecting that the GDAL utilities are doing<br>
>> the looking. That isn't how it works. Instead, the system loader does the<br>
>> search based on what the utility says it needs.<br>
>><br>
>> That is, a dynamically linked gdalinfo says the "what", not the "where".<br>
<br>
This isn't entirely accurate.   An executable (or another library) lists<br>
the needed libraries and the search paths.<br>
<br>
>> If you put your libraries somewhere non-standard, you need to tell the system<br>
>> where to get them from. Usually LD_LIBRARY_PATH environment variable or<br>
>> something like that will help.<br>
<br>
Variables like that can help, but having to set them is working around a bug.<br>
<br>
> That would rather be DYLD_LIBRARY_PATH on Mac<br>
><br>
> Building GDAL with "cmake -DGDAL_SET_INSTALL_RELATIVE_RPATH=ON" might<br>
> also help. Cf<br>
> <a href="https://gdal.org/build_hints.html#cmdoption-arg-GDAL_SET_INSTALL_RELATIVE_RPATH" rel="noreferrer" target="_blank">https://gdal.org/build_hints.html#cmdoption-arg-GDAL_SET_INSTALL_RELATIVE_RPATH</a><br>
<br>
Indeed, cmake is very messy about RPATH.  Some operating systems seem to<br>
object to rpath settings, and for whatever reason, cmake doesn't default<br>
to doing this the way I consider correct, and further seems to push some<br>
of the decisions to the project.  Compare to autoconf/libtool, which has<br>
"the way rpath ought to be" doctrine embedded, which is good if you<br>
agree and not so good if you don't.<br>
<br>
So basically you need to understand how shlib searching works, and then<br>
you need to understand the various cmake options, and figure it out.<br>
<br>
"objdump -a" is useful to inspect objects on normal systems, and otool<br>
is useful on macOS.  (Despite using and working on pkgsrc for macs I<br>
have not yet fully paged in how shared libraries work on macs.  But<br>
pkgsrc installs programs in /opt/pkg/bin that find libraries in<br>
/opt/pkg/lib just fine.)<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>