[gdal-dev] Python Wheels for gdal

[Idan Miara]

>From what I can see, the gdal302.dll inside
https://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal doesn't depend on any
non-windows DLL. All its dependencies are statically linked.

Maybe until a better solution is found, and to remedy all the windows users
who just want to `pip install gdal`,
We could push Christoph Gohlke's wheels to pypi ?
What happens if both source wheels and binary wheels are available with the
same package name?
Would then `pip install gdal` pick up the src package on Linux and the
binary package on Windows?
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.

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`:
https://pypi.org/project/gdal-ecw/
https://github.com/talos-gis/gdal-ecw
Maybe all the other drivers (non MIT licensed) could be installed this way.

Idan

On Sat, 1 Feb 2020 at 16:01, Even Rouault <even.rouault at spatialys.com>
wrote:

> > There are existing tools. Multibuild uses
> > https://github.com/pypa/auditwheel. It says in the project README that
> the
> > result is "like static linking"
>
> From what I understood, this is far from being static linking. It just
> plays
> with the RPATH to make sure that the .so from the wheel .libs directory
> are
> loaded instead of other from the system paths. But if within the same
> process,
> you have symbols with same name coming from different .so (like libhdf5
> coming
> from rasterio wheel and another one coming from h5py), then game over.
>
> Playing with my idea of symbol renaming, I've discovered this jewel:
> https://github.com/lief-project/LIEF
> It has a super simple Python API to manipulate ELF, PE and Mach-O objects.
> I
> gave it a try with Linux ELF and rasterio wheels
>
> Small python script and instructions at:
> https://gist.github.com/rouault/5e92eb046b7c451b8b0071e9d765c9de
>
> The result is a patched rasterio wheel where .so files in rasterio/.libs/
> have
> all their exported symbols prefixed with _rasterio_whl_  and the
> rasterio/*.so
> files are modified to import those _rasterio_whl_ symbols. So we have in
> theory full symbol isolation. The resulting rasterio seems to be
> functional
> (at least rasterio.open() works), although I didn't have an initial
> situation
> where I could make it crash when loading gdal python bindings or h5py.
> Would
> be cool if someone that has a crashing setup could confirm that this
> actually
> fixes it.
>
> But... there is a downside preventing this to be used in production. lief
> has
> a bug / inefficency: the symbol renaming creates .so larger than expected.
> In
> particular, with the netcdf lib that jumps from 1.9 MB to 52 MB !
> Reported as https://github.com/lief-project/LIEF/issues/379
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210217/1f13d4b4/attachment.html>