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