Open jamesmcclain opened 4 years ago
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#L3That 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.
A possible solution to https://github.com/geotrellis/gdal-warp-bindings/issues/73 is to load the library at runtime rather than linking directly to it.