Consider dlopen(3) as Solution to Macintosh Linkage Questions

[jamesmcclain]

A possible solution to #73 is to load the library at runtime rather than linking directly to it.

[CloudNiner]

The following is pasted from slack conversation with @jamesmcclain as the first set of steps to follow to address this issue:

So we would need another copy of this line https://github.com/geotrellis/gdal-warp-bindings/blob/master/src/Makefile#L27-L28 explicitly build libgdalwarp_bindings.dylib separately from the .so version and correspondingly, the "gdal-related" part of this variable would not be used https://github.com/geotrellis/gdal-warp-bindings/blob/master/src/Makefile#L3

That produces a binary that does not have a gdal shared library as a runtime dependency (actually, the build would fail, but that would be fixed subsequently)

Next, to allow the build to succeed, these lines would be conditionally removed from the macintosh build https://github.com/geotrellis/gdal-warp-bindings/blob/master/src/locked_dataset.hpp#L34-L35 and the references to those functions would be replaced with initially unspecified function pointers which will then be filled in with dlsym (https://linux.die.net/man/3/dlopen)

There are a few practical difficulties: how does one get the gdal library filename on macintosh (there is some culture/system-specific stuff that has to be negotiated)

Can we assume a particular file name, with the user configuring LD_LIBRARY_PATH? (James is unsure, macos is unfamiliar)

Also, there would be a slight performance hit to the library because you would have to jump on a trampoline every time you call out to gdal

Understood. Our use case is generally to use MacOS as development environment so this isn't anticipated to be a problem. All our production systems are running linux.

[jamesmcclain]

https://stackoverflow.com/questions/62705287/win32-equivalent-of-dlopennull