Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build with external geotiff library option #110

Closed
Crghilardi opened this issue Jan 2, 2021 · 4 comments
Closed

build with external geotiff library option #110

Crghilardi opened this issue Jan 2, 2021 · 4 comments

Comments

@Crghilardi
Copy link

GDAL uses an internal version of libgeotiff shipped with the code by default but can use an external version using a --with-geotiff flag. Currently, GDAL_jll is built using the default internal version.

Building with an external libgeotiff would be mainly be useful for a wrapping PDAL for BinaryBuilder in the future. The change to the build seems fairly simple but I have no idea how this impacts the wrapper functions.

Opening an issue here for discussion.

@visr
Copy link
Member

visr commented Jan 2, 2021

I can't really find much discussion online over differences between the two. The GDAL docs mention that for certain options libgeotiff 1.6 needs to be used, and I see the latest release, 1.6, has been built in Yggdrasil.

The same goes for libtiff as well. I can only find some old issues where the internal version was better, but perhaps this has been fixed now: https://bugs.archlinux.org/task/24720

For the wrapper functions I'm fairly sure it wouldn't make any difference.

If anyone knows a good reason to not use external libtiff or libgeotiff, give a shout. Otherwise, I think it'd be good to do so.

@Crghilardi
Copy link
Author

Collecting some notes here, possible reasons include:

  1. BigTiff (>4GB tiff images) issues?
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733 and Arch issue mentioned above

  2. Collisions with system installed libtiff libraries?
    https://www.orfeo-toolbox.org/CookBook-6.4/FAQ.html#debian-linux-ubuntu)
    https://bugzilla.redhat.com/show_bug.cgi?id=178162)
    https://sourceforge.net/p/saga-gis/mailman/saga-gis-developer/?viewmonth=201206)

A lot of the existing links I am finding are fairly old and mentioned GDAL versions 1.X.Z. The most recent thing i could find is from the "barn raising" refactoring effort in 2018.

I don't know if any of this has been fixed in the more recent versions.

Also I don't quite understand if you can use use one internal + one external or if you have to use both internal/external libgeotiff + libtiff at the same time?

Maybe worth an issue/email to mailing list to clarify?

@visr
Copy link
Member

visr commented Jan 2, 2021

Thanks for doing the extra research. The issues I see are really quite old, so I think it's quite safe to make this switch now. And with JLL packages we don't need to worry about collisions with system install libtiff.

Looking at the commits in https://github.com/OSGeo/gdal/tree/master/gdal/frmts/gtiff/libgeotiff they sync regularly, and the devs are the same as well.

Also I don't quite understand if you can use use one internal + one external or if you have to use both internal/external libgeotiff + libtiff at the same time?

I'm not sure. If we try anything that is not possible autotools will probably shout at us :) I think since both are already available as a standalone JLL, we should just go for both at the same time.

If you wish you can of course ask the mailing list. But we can also just see if it works first.

@Crghilardi
Copy link
Author

Closed in Yggdrasil PR #2341

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants