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
PS. Apologies - my last email (below) was premature and resulted from a lack
of effort on my own part.
I’ve solved this lastest issue now.
I don’t need Python bindings in this case, so the easiest solution (instead of
installing and/or pointing cmake to a compatible Python environment) is of
Hi John,
Thanks for this information. This was definitely not the case when I first
started building iOS apps (quite some time ago), so I’ll have to do some
further research to make sure I can incorporate dynamic libraries if/when
appropriate.
Cheers,
Nik.
> On 4 Jul 2022, at 1:16 pm, John
Nik,
You can definitely use dynamic linking in an iOS app.
I don’t know how you would do that in CMake.
John Daniel
Etresoft, Inc.
On Jul 3, 2022, at 9:17 PM, Nik Sands wrote:
Hi Even,
Thanks for the suggestions. I am now using '$HOME' instead of ‘~’. I’m using
static libraries instead o
Hi Even,
Thanks for the suggestions. I am now using '$HOME' instead of ‘~’. I’m using
static libraries instead of dynamic libraries because my goal is to build GDAL
for iOS once I get the process working for macOS and my understanding is that I
cannot use dynamic linking in an iOS app (except
