Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#30471 - [gdal] Rename tiff and geotiff internal symbols

Attached to Project: Community Packages
Opened by Manuel Grizonnet (grizonnetm) - Thursday, 28 June 2012, 10:22 GMT
Last edited by György Balló (City-busz) - Sunday, 08 September 2013, 10:55 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Jaroslav Lichtblau (Dragonlord)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

There is a blocking issue with the gdal 1.9 package for OTB users and more generally on other tools which depends on gdal and want to use TIFF images.
The OTB package cannot read any TIFF file without crashing using this package and the same issue can be seen on Debian unstable or UbuntuGIS repository.

This is a long time issue that affect other image processing software or GIS (like QGIS) which use GDAL but we have never been so close to a solution.
Indeed, adding:

--with-rename-internal-libtiff-symbols=yes
--with-rename-internal-libgeotiff-symbols=yes

in the gdal configuration file of the package, the problem goes away (available since gdal version 1.9.0).

More information on this subject in this thread on UbuntuGIS :ubuntu@lists.osgeo.org/msg00330.html"> http://www.mail-archive.com/ubuntu@lists.osgeo.org/msg00330.html

Don't hesitate if you need further details.

Regards,

Manuel
This task depends upon

Closed by  György Balló (City-busz)
Sunday, 08 September 2013, 10:55 GMT
Reason for closing:  Fixed
Comment by Manuel Grizonnet (grizonnetm) - Monday, 27 May 2013, 05:25 GMT
  • Field changed: Percent Complete (100% → 0%)
I re-open this request as it is still a blocking issue for users which want to link with gdal (like Sextante inside QGIS for example)

Note that this modification was adopted last year by ubuntugis:
https://launchpad.net/~ubuntugis

Don't hesitate if you need further informations.

Cheers,

Manuel



Comment by Sven-Hendrik Haase (Svenstaro) - Monday, 27 May 2013, 05:25 GMT
Dragonlord, you should probably at least explain why you choose not to fix this. I think I'm missing some context here.
Comment by Manuel Grizonnet (grizonnetm) - Monday, 08 July 2013, 06:53 GMT
Hi,

FYI this modification as been accepted by debian packager and will be included in Debian testing.

See Fransceco Lovergine message on Debian GIS mailing list:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712688
Comment by Alister Hood (Alister) - Tuesday, 30 July 2013, 00:14 GMT
Doesn't the current package use external tiff/geotiff, so this is irrelevant?
Comment by Manuel Grizonnet (grizonnetm) - Tuesday, 30 July 2013, 06:58 GMT
don't think so or perhaps with recent version.

Generally gdal packages are built with internal versions of tiff and geotiff to activate the bigtiff support.

That's the case for the gdal package in UbuntuGIS for example (see the configure command at the beginning og the buildlog):
https://launchpadlibrarian.net/144550942/buildlog_ubuntu-quantal-amd64.gdal_1.10.0-1~quantal1_UPLOADING.txt.gz
Comment by Alister Hood (Alister) - Tuesday, 30 July 2013, 08:00 GMT
The current package is using this, and has libgeotiff and libtiff as depends:

./configure --prefix=/usr --with-netcdf --with-libtiff --with-sqlite3 \
--with-geotiff --with-mysql --with-python --without-libtool --with-curl \
--with-hdf5 --with-perl --with-geos --with-png
Comment by György Balló (City-busz) - Sunday, 08 September 2013, 03:25 GMT
Could you explain the following things?

1. Is this still a problem with gdal 1.10.0-2?

2. Is there any way to easily reproduce the problem?

3. Is there any known regression if we add these configuration options?
Comment by Alister Hood (Alister) - Sunday, 08 September 2013, 08:01 GMT
I don't see how this could be an issue, because the current package is using external tiff/geotiff.
And regarding what Manuel says, I don't think there is a need to use internal tiff/geotiff, because we have the latest libtiff. At http://gdal.org/frmt_gtiff.html it says: "When built with internal libtiff or with libtiff >= 4.0, GDAL also supports reading and writing BigTIFF files"
Comment by György Balló (City-busz) - Sunday, 08 September 2013, 10:55 GMT
Okay, thanks for the explanation, I see also that gdal built with external tiff/geotiff, so it's no longer a problem.

Loading...