<div dir="ltr">From what I can see, the gdal302.dll inside <a href="https://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal">https://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal</a> doesn't depend on any non-windows DLL. All its dependencies are statically linked.<div><br><div style="direction:ltr">Maybe until a better solution is found, and to remedy all the windows users who just want to `pip install gdal`, </div><div>We could push Christoph Gohlke's wheels to pypi ? </div><div>What happens if both source wheels and binary wheels are available with the same package name? </div><div>Would then `pip install gdal` pick up the src package on Linux and the binary package on Windows? </div><div>We could also consider merging all the pyd files from the wheels of cp36-cp39 into a single wheel if it makes the distribution easier.</div><div><br></div><div>I've just asked 

Christoph 

to uncomment the gdalplugins loading section from the __init__.py file so that plugins can be installed seamlessly, i.e. `pip install gdal-ecw`:</div><div><a href="https://pypi.org/project/gdal-ecw/">https://pypi.org/project/gdal-ecw/</a><br></div><div><a href="https://github.com/talos-gis/gdal-ecw">https://github.com/talos-gis/gdal-ecw</a><br></div><div>Maybe all the other drivers (non MIT licensed) could be installed this way.</div><div><div><br></div></div></div><div>Idan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 1 Feb 2020 at 16:01, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> There are existing tools. Multibuild uses<br>
> <a href="https://github.com/pypa/auditwheel" rel="noreferrer" target="_blank">https://github.com/pypa/auditwheel</a>. It says in the project README that the<br>
> result is "like static linking"<br>
<br>
>From what I understood, this is far from being static linking. It just plays <br>
with the RPATH to make sure that the .so from the wheel .libs directory are <br>
loaded instead of other from the system paths. But if within the same process, <br>
you have symbols with same name coming from different .so (like libhdf5 coming <br>
from rasterio wheel and another one coming from h5py), then game over.<br>
<br>
Playing with my idea of symbol renaming, I've discovered this jewel:<br>
<a href="https://github.com/lief-project/LIEF" rel="noreferrer" target="_blank">https://github.com/lief-project/LIEF</a><br>
It has a super simple Python API to manipulate ELF, PE and Mach-O objects. I <br>
gave it a try with Linux ELF and rasterio wheels<br>
<br>
Small python script and instructions at:<br>
<a href="https://gist.github.com/rouault/5e92eb046b7c451b8b0071e9d765c9de" rel="noreferrer" target="_blank">https://gist.github.com/rouault/5e92eb046b7c451b8b0071e9d765c9de</a><br>
<br>
The result is a patched rasterio wheel where .so files in rasterio/.libs/ have <br>
all their exported symbols prefixed with _rasterio_whl_  and the rasterio/*.so <br>
files are modified to import those _rasterio_whl_ symbols. So we have in <br>
theory full symbol isolation. The resulting rasterio seems to be functional <br>
(at least rasterio.open() works), although I didn't have an initial situation <br>
where I could make it crash when loading gdal python bindings or h5py. Would <br>
be cool if someone that has a crashing setup could confirm that this actually <br>
fixes it.<br>
<br>
But... there is a downside preventing this to be used in production. lief has <br>
a bug / inefficency: the symbol renaming creates .so larger than expected. In <br>
particular, with the netcdf lib that jumps from 1.9 MB to 52 MB !<br>
Reported as <a href="https://github.com/lief-project/LIEF/issues/379" rel="noreferrer" target="_blank">https://github.com/lief-project/LIEF/issues/379</a><br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></blockquote></div>