On 19/02/15 19:57, Even Rouault wrote:
Le jeudi 19 février 2015 18:43:06, Moritz Lennert a écrit :
Hi,
I do'nt know if this is more an issue for DebianGIS, but I have the
feeling it is an upstream issue, so I'm posting it here. Please redirect
me if you think I'm wrong.
I'm trying to activate MrSID support for GDAL.
I downloaded and unpacked MrSID_DSDK-9.1.0.4045-linux.x86-64.gcc44.
Then I ran the following on a Debian testing machine:
**
apt-get source gdal
cd gdal-1.10.1+dfsg/
debian/rules gdal-mrsid (which AFAIU basically just creates
libgdal-mrsid-1.10.1.tar.gz and copies it to the directory above the
GDAL source directory)
cd ../
tar xvzf libgdal-mrsid-1.10.1.tar.gz
cd libgdal-mrsid-1.10.1/
chmod +x configure
./configure --with-gdal=/usr/bin/gdal-config
--with-mrsid=/home/mlennert/SRC/MrSID_DSDK-9.1.0.4045-linux.x86-64.gcc44/Ra
ster_DSDK --with-jp2mrsid=no
make
sudo make install
**
I do not get any error message, but when I run
gdalinfo --formats | grep -i sid
the MrSID format is not listed.
I ran ldd on the plugin .so installed in /usr/lib/gdalplugin
and saw that it couldn't find libltidsdk.so.
So I set
export
LD_LIBRARY_PATH=/home/mlennert/SRC/MrSID_DSDK-9.1.0.4045-linux.x86-64.gcc44
/Raster_DSDK/lib/
and now ldd could find the library, but MrSID is still not listed
amongst the available formats.
Moritz,
If once you've set LD_LIBRARY_PATH, ldd doesn't report any unfound library,
then you could check if GDAL_DRIVER_PATH is defined and make point it to
/usr/lib/gdalplugin (although that path should be hardcoded in the GDAL
library by default)
Setting GDAL_DRIVER_PATH did the trick. Thanks for the hint !
Before adding this info to the wiki as Jeff suggested, I think we should
investigate why this path is not set by default as you say.
In gcore/gdaldrivermanager.cpp I read:
"There are a few rules for the driver path. If the GDAL_DRIVER_PATH
environment variable it set, it is taken to be a list of directories to
search separated by colons on UNIX, or semi-colons on Windows.
Otherwise the /usr/local/lib/gdalplugins directory, and (if known) the
lib/gdalplugins subdirectory of the gdal home directory are searched on
UNIX and $(BINDIR)\gdalplugins on Windows."
So, /usr/lib/gdalplugins (which is where the plugin gets installed by
default using the process I explained) does not seem to be in the list
of hardcoded paths. So, maybe '/usr/lib/gdalplugins' could be added to
the search path ? It does seem a fairly standard path...
- The SDK contains libgeos.so files but in a version that seems older
than the one in Debian Jessie. Could that be a source of conflict that
keeps GDAL from recognizing the plugin ?
Hum, that might cause problem, or not, but I assume they would appear later
with crashes or nasty behaviour when actually reading a raster. But that
shouldn't prevent the plugin from being used.
I'll look out for that. A first reading into QGIS did not show any problems.
Moritz
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
