Hello,
I'm reviving an already known problem about the gdal packages for
Ubuntu/Debian, related to the use of the hide-internal-symbols configure
option.
To sum it up, we get into troubles with the gdal packages since we also
use the geotiff API.
Until recently, we knew only about a proble
Julien,
To be fair, I think that --with-hide-internal-symbols just does what it
advertizes : it hides GDAL internal symbols (internal libtiff, internal
libgeotiff) to applications that link with libgdal. I mean that they cannot use
those symbols (if they only link to libgdal). The advantage is tha
Even,
I am working with Julien on the same project, and you are right about
the --hide-internal-symbols option : if symbols are not hidden, we
recognize that gdal exposes tiff symbols and we manage to deal with this
case by forcing all tiff access to use gdal internal tiff library (we
have to
Hello Even,
Thank you for your answer.
Le 29/11/2010 15:51, Even Rouault a écrit :
Julien,
To be fair, I think that --with-hide-internal-symbols just does what it
advertizes : it hides GDAL internal symbols (internal libtiff, internal
libgeotiff) to applications that link with libgdal. I mean
Hello,
As it seems like the gdal 1.8 debian package is not out yet, maybe there
is still some time left to tackle this issue for the next gdal debian
package.
To sum up the current situation when reading TIFF files with gdal :
- this program :
http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa5
Le mardi 26 avril 2011 18:36:45, Julien Malik a écrit :
> Hello,
>
> As it seems like the gdal 1.8 debian package is not out yet, maybe there
> is still some time left to tackle this issue for the next gdal debian
> package.
>
> To sum up the current situation when reading TIFF files with gdal :
On Tue, Apr 26, 2011 at 07:55:00PM +0200, Even Rouault wrote:
> > What can we do to help find a solution (what kind of modification to the
> > gdal debian package would you agree to make to solve this issue) ?
>
> I'm not sure the solution is really in the debian packaging...
>
> There are indeed
Hi Even,
Quoting Even Rouault :
Le mardi 26 avril 2011 18:36:45, Julien Malik a écrit :
Hello,
As it seems like the gdal 1.8 debian package is not out yet, maybe there
is still some time left to tackle this issue for the next gdal debian
package.
To sum up the current situation when reading
> All this comes from the fact that Orfeo Toolbox has ossim as one of
> its main dependency, and ossim handles TIFF via libgeotiff and not via
> gdal.
> For example :
> http://trac.osgeo.org/ossim/browser/trunk/ossim/src/ossim/support_data/ossi
> mGeoTiff.cpp which makes extensive use of the geoti
Quoting "Francesco P. Lovergine" :
On Tue, Apr 26, 2011 at 07:55:00PM +0200, Even Rouault wrote:
> What can we do to help find a solution (what kind of modification to the
> gdal debian package would you agree to make to solve this issue) ?
I'm not sure the solution is really in the debian pac
On Tue, Apr 26, 2011 at 09:39:21PM +0200, MALIK Julien wrote:
> >
> >Here we go:
> >
> >http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id293268
> >
> >of course this is a possibile solution to avoid symbol collision among
> >different libraries. It is not a os-independent so
Note that it will sacrify binary compatibility against casual builds.
You will need to build against the Debian version of GDAL, not third
parties builds.
For casual builds, we have another solution : don't use
hide-internal-symbols, and install the tiff/geotiff headers from gdal
source tree
12 matches
Mail list logo
