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 <[email protected]> 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 combine them into a fat library and use that in my project (which is what I've been doing successfully for GDAL 2.2.2 for some time). GDAL 3.6 isn't yet released, so I'm working with 3.5 for now in order to get my build process right. I believe that for iOS, I cannot use any 'homebrew' or 'macports' packages installed in /usr/local, etc, as dependencies for the GDAL build. They will likely work for macOS, but not for iOS. Therefore I will need to build any dependencies manually and install to another location (for both iOS and macOS), where they do not already exist in the standard macOS/iOS SDK locations (or where the Apple-supplied libraries in those SDK locations are otherwise incompatible with GDAL - see SQLite notes below). For any such dependencies, I plan to install them in ~/build (as I did previously for GDAL 2.2.2). So I'm starting out building simply for macOS, but trying to use a similar technique to what I hope to use for iOS (after I get it working for macOS). Unfortunately, an Intel Mac build is not going to help much for iOS. The macOS operating system includes many accommodations, like DYLD_LIBRARY_PATH, for legacy unix tools like GDAL. You don’t get those on iOS. It is going to be an awful lot of work to get GDAL to build on a Mac and then you are going to hit a brick wall with iOS. Furthermore, some of GDAL’s optional dependencies are much more difficult to build for iOS. And there are some subtle differences between macOS and iOS. libcurl, for example, doesn’t exist on iOS. If you want it, you will have to build it yourself. I think it has a special mode where it can link against the built-in crypto frameworks instead of OpenSSL. Otherwise, that will complicate your life if you want to distribute your work in the App Store. On iOS especially, it is better to hook into the system-provided networking architectures instead of relying on unix ports. If you want to proceed anyway, here are my recommendations: 1) Forget macOS. Focus on iOS. Targeting iOS 14+ should be adequate. Once you get iOS working, the macOS version is little more than a few additional clicks. Dependences will continue to be a mess, however. 2) Get an Apple Silicon Mac. This isn’t a requirement, but an Intel Mac is little more than a boat anchor as far as developers are concerned. 3) You will also need a development iOS device that you will keep on your lowest supported version of iOS. You don’t want to bother building GDAL for the simulator. Minimize your misery and target only a real device. 4) For now, only build GDAL with no dependencies. 5) The only thing you want to build is a framework. Once you have a useable iOS framework, making a macOS framework will be trivial by comparison. Then you can bundle them both into an xcframework. 6) Don’t forget PROJ and various data directories. You can include the data directories in your resources. But you will have to manually bootstrap the paths. If you need write access to any of that data, your bootstrap will have to including copying the data to an application support path and using that as the directory. I’m afraid I can’t help you do any of that in CMake. Supposedly, it has a cross-platform mode. I think it can also generate either frameworks and/or Xcode projects. I can’t say how well any of that works. This is one of those times where you will have to become the expert. Most iOS and Mac developers don’t use CMake. Most CMake developers don’t use iOS or Mac. Same goes for most GDAL developers. You’re on your own here. But if you are successful, you could become THE expert for building and running GDAL on iOS and macOS, much as the kyngchaos fellow used to be. John Daniel Etresoft, Inc. On Jul 4, 2022, at 12:19 AM, Nik Sands <[email protected]> wrote: 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 the exact error message, before I rebuilt GDAL as a static library ( BUILD_SHARED_LIBS=OFF ), after which of course gdalinfo works fine. 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? Cheers, Nik. ======================================================== NIK SANDS Line Tamer | Time Traveller | Space Cadet _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
