Nik,
In another message you indicated that your ultimate goal was an iOS build. You
also said this a few days ago, but I missed it:
On Jul 1, 2022, at 3:58 AM, Nik Sands wrote:
My ultimate aim is to build GDAL 3.6 (not yet released) for iOS on ARM (as well
as for macOS on Intel). I can then c
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 wrote:
>
> Even Rouault writes:
>
> > Le 04/07/202
Even Rouault 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
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 expect
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 l
Hi GDAL devs,
After having just succeeded in getting GDAL to build on macOS using a
non-default CMAKE_INSTALL_PREFIX, I found that gdalinfo fails because it cannot
find gdal.dylib in /usr/lib. I assume other utilities also fail with the same
error, but I didn’t try them.
Sorry I didn’t copy t
