rasterio / rasterio-wheels

MIT License
11 stars 16 forks source link

use external libtiff #65

Closed vincentsarago closed 3 years ago

vincentsarago commented 3 years ago

This is not an issue so please feel free to close if you don't have the time to answer ;-)

So with the new rasterio wheels you updated proj to 7.2 which require libtiff but when looking at the build config I can't find where libtiff gets installed 🤷

https://github.com/rasterio/rasterio-wheels/blob/df979bcbcf6365c533a89d037e8951343b3e3ebd/config.sh#L17-L33

sgillies commented 3 years ago

Oh, good question, @vincentsarago . I had forgotten about this detail. I would bet that PROJ's configure phase looks for libtiff on the system and if it doesn't find it, continues without the features. GDAL does this quite a bit. I checked the wheels and both the manylinux and macos wheels include a libtiff. I believe it gets built when we run build_lcms2 at https://github.com/rasterio/rasterio-wheels/blob/master/config.sh#L80, which runs https://github.com/matthew-brett/multibuild/blob/6e9f609a33d78baaa96b92ad8d876bc90dcc7741/library_builders.sh#L215.

Now, GDAL is configured to use its internal libtiff, which means we have two copies in the wheel. I think this should be fixed before 1.2.0.

vincentsarago commented 3 years ago

@sgillies this is not a bug, I think it's fine to have two libtiff because GDAL internal libtiff has usually the latest advancement, while it can take some time to be merge and publish upstream!

To be honest, I asked the question because in https://github.com/lambgeo/docker-lambda I was first building GDAL using external libtiff (used for PROJ and GDAL) but I'm seeing some weird tiff error so I'm trying to switch back to having 2 libtifff, but sadly I'm getting compilation errors 🤷‍♂️

vincentsarago commented 3 years ago

Update: libtiff 4.2.0 was just released and include latests change about libdeflate (ref: #67)

https://twitter.com/EvenRouault/status/1340408328271372289?s=20

I think it will then be fine to build libtiff (against libdeflate) and then build gdal against this external libtiff.

vincentsarago commented 3 years ago

FYI, I spent quite some time to finally be able to compile GDAL using external libtiff (to only ship one version of libtiff). important finding on my side is that I HAD to also use external libgeotiff

https://github.com/lambgeo/docker-lambda/blob/master/dockerfiles/gdal3.2/Dockerfile#L19-L67

sgillies commented 3 years ago

This is going to be done in the next update and will appear in the 1.3.0 wheels.