[gdal-dev] CMAKE_INSTALL_PREFIX gdalinfo still looks for .dylib in /usr/lib

[Paul Harwood]

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 <gdt at lexort.com> wrote:

>
> Even Rouault <even.rouault at 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220704/05f70ba4/attachment-0001.htm>