How to make libspatialite use an alternative sqlite3?

[David Segersson]

I'm building libspatialite4.3 on CentOS 6.5 and cannot make it link to the libsqlite3 I want. The system sqlite3 is old and gives me compile errors that have been reported before by other users. I've therefore compiled a newer sqlite3 (3.20) in an alternative location. I've given configure LDFLAGS pointing at this location. The compilation goes fine but checking with ldd afterwards reveals that the libspatialite.so is still using the old system libsqlite3.so

If I ignore this I get problems when building Spatialite-tools. I then get the error:

/home/sm_davse/virtualenvs/gdalenv/lib/libspatialite.so: undefined reference to `sqlite3_create_function_v2'

I suspect that this error comes from using the outdated system sqlite3.

When building libspatialite I'm running configure like this:

CPPFLAGS=-I/home/sm_davse/virtualenvs/gdalenv/include LDFLAGS=-L/home/sm_davse/virtualenvs/gdalenv/lib PKG_CONFIG_PATH=/home/sm_davse/virtualenvs/gdalenv/lib/pkgconfig ./configure --prefix /home/sm_davse/virtualenvs/gdalenv --build=x86_64-redhat-linux-gnu

The CPPFLAGS and LDFLAGS let configure find my proj4 installation. The new sqlite3 is in the same directories but is not found.

I had to use the "--build=x86_64-redhat-linux-gnu" flag because I got error messages saying that the machine was unknown.

Adding the directory of my new sqlite3 to LD_LIBRARY_PATH does not seem to help.

I've even tried changing the RPATH of the libspatialite.so using chrpath. After this ldd reported libspatialite to link to the correct sqlite3. However, building Spatialite-tools I still get the same error. I take this as an indication that libspatialite was actually compiled using the system sqlite3 and therefore changing the rpath afterwards will not help.

I do not have root access, so I cannot replace the system sqlite3.

Does anybody have an idea how to make libspatialite use a specific libsqlite3.so?

David

[mj10777]

On Tuesday, 12 September 2017 17:29:02 UTC+2, David Segersson wrote:

I'm building libspatialite4.3 on CentOS 6.5 and cannot make it link to the libsqlite3 I want. The system sqlite3 is old and gives me compile errors that have been reported before by other users. I've therefore compiled a newer sqlite3 (3.20) in an alternative location. I've given configure LDFLAGS pointing at this location. The compilation goes fine but checking with ldd afterwards reveals that the libspatialite.so is still using the old system libsqlite3.so

For the following paths:

CPATH

LDFLAGS

LD_LIBRARY_PATH

it is important to set the order in which the given directories should be searched

- that what is found first: wins

When running a program that used the libraries

- LD_LIBRARY_PATH must also be set that your version of libsqlite3 is found first.

These should be set in your local '.bashrc' file to insure, for your user, this order will be used.

- any changes take effect after the opening of a new terminal or process

Before compiling (or running) spatiallie-tools, do a

echo -e "-I-> LD_LIBRARY_PATH[${LD_LIBRARY_PATH}]\nLDFLAGS[${LDFLAGS}]\nCPATH[${CPATH}]"

and make sure that the directory containing your libsqlite3 comes before the libsqlite3 you do not want to use.

 Mark

[a.fu...@lqt.it]

Hi David,

it casually happens that www.gaia-gis.it is hosted on
CentOS 6.9, so I've attempted to reproduce your issues
on this server. but I simply discovered that the whole
build process was absolutely uneventful.
here is the exact log of my operations:

----------------------------------------------------
building SQLite 3.20.1
======================
wget https://www.sqlite.org/2017/sqlite-autoconf-3200100.tar.gz
tar zxvf sqlite-autoconf-3200100.tar.gz
cd sqlite-autoconf-3200100
./configure --prefix=/home/sandro/test
make -j8
make install


building libspatialite-4.3.0a
=============================
cd ..
wget
http://www.gaia-gis.it/gaia-sins/libspatialite-sources/libspatialite-4.3.0a.tar.gz
tar zxvf libspatialite-4.3.0a.tar.gz
./configure --prefix=/home/sandro/test --enable-freexl=no
make -j8
make install


building spatialite-tools-4.3.0
===============================
cd ..
wget
http://www.gaia-gis.it/gaia-sins/spatialite-tools-sources/spatialite-tools-4.3.0.tar.gz
tar zxvf spatialite-tools-4.3.0.tar.gz
export "PKG_CONFIG_PATH=/home/sandro/test/lib/pkgconfig"
./configure --prefix=/home/sandro/test --enable-freexl=no
--enable-readosm=no
make -j8
make install


final check
===========
/home/sandro/test/bin/spatialite

spatialite> SELECT sqlite_version();
3.20.1
spatialite> SELECT spatialite_version();
4.3.0a
spatialite> SELECT spatialite_target_cpu();
x86_64-redhat-linux
----------------------------------------------------

note:
when building spatialite-tools I received a fatal error
caused by an undeclared XML_PARSE_BIG_LINES
(the version of libxml2 supported by CentOS is really
obsolete); I just replaced the constant with a 0
value and after applying this quick&dirty patch the
build was finally successful.

bye Sandro

[David Segersson]

Hi Sadro,

I'm building spatialite on a cluster, maybe there are some configuration differences...

I've tried again just following the same procedure as you:

sqlite3 installs without problems

spatialite4.3

1. First I get errors related to sqlite3.h not found. I assume the system sqlite is picked up and it lacks .h files.

2. I found sqlite3.pc in /home/sm_davse/virtualenvs/gdalenv/lib/pkgconfig so I instead try:

./configure --prefix /home/sm_davse/virtualenvs/gdalenv PKG_CONFIG_LIBDIR="/home/sm_davse/virtualenvs/gdalenv/lib/pkgconfig"

However, the sqlite3.h files are still not found. It seems like the sqlite3.pc is not used.

3. I instead try to set LDFLAGS and CPPFLAGS manually:

./configure --prefix /home/sm_davse/virtualenvs/gdalenv CPPFLAGS=-I/home/sm_davse/virtualenvs/gdalenv/include LDFLAGS=-L/home/sm_davse/virtualenvs/gdalenv/lib

the configure then completes without errors. During make I get erros for not finding geos header files, so I add that also to CPPFLAGS.

./configure --prefix /home/sm_davse/virtualenvs/gdalenv CPPFLAGS="-I/home/sm_davse/virtualenvs/gdalenv/include -I/software/apps/geos/3.4.2/i1501/include" LDFLAGS=-L/home/sm_davse/virtualenvs/gdalenv/lib

make -j16

This completes successfully.

I make sure LD_LIBRARY_PATH contains /home/sm_davse/virtualenvs/gdalenv/lib

ldd /home/sm_davse/virtualenvs/gdalenv/lib/libspatialite.so returns:

libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00002b8600c67000)

[David Segersson]

...continue from previous post (I posted by accident, sitting on the tram...)

my conclusion is that the linking is using paths from somwhere else and giving higher priority to system paths. Since it seems like PKG_CONFIG_LIBDIR is not used, maybe a standard PKG_CONFIG_PATH is picked up?

By the way, thanks for taking the time to look into my problem!

David

[David Segersson]

Solved,

It showed out that libspatialite was actually compiled against the correct sqlite3, but for some reason the rpath of the libraries included the path to the system sqlite3 before the new sqlite3. I just changed the order of directories in the rpath using chrpath and then everything worked.

David