On 20/02/15 18:08, Even Rouault wrote:
Le vendredi 20 février 2015 12:16:55, Moritz Lennert a écrit :
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.gc
c44 /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...
There's this snippet of code as well:
#ifdef GDAL_PREFIX
papszSearchPath = CSLAddString( papszSearchPath,
#ifdef MACOSX_FRAMEWORK
GDAL_PREFIX "/PlugIns");
#else
GDAL_PREFIX "/lib/gdalplugins" );
#endif
If you look at port/cpl_config.h, you'll see a #define GDAL_PREFIX with the
installation prefix, so for example /usr if you ran ./configure --prefix=/usr,
which makes /usr/lib/gdalplugins to be searched.
Sorry for the delay in replying:
port/cpl_config.h shows this:
/* --prefix directory for GDAL install */
#define GDAL_PREFIX "/usr"
so does, obviously 'gdal-config --prefix'.
So it's a bit mysterious to me why I have to set GDAL_DRIVER_PATH...
Moritz
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
