QGIS Python error "RuntimeError: Cannot find any suitable spatialite module"

English Applications
1

Hi
I have a problem with QGIS Data Base Administration.
My system is running Open Suse Leap 15.2, x86 64 bit
This issue occurs both with QGIS 3.16 and 3.18

Whenever I try to use the Data Base Administration tool I get a Python error

The messages window shows the following.

2021-04-22T22:34:54 WARNING Traceback (most recent call last):
File “/usr/share/qgis/python/plugins/db_manager/db_model.py”, line 456, in rowCount
self._refreshIndex(parent, True)
File “/usr/share/qgis/python/plugins/db_manager/db_model.py”, line 505, in _refreshIndex
if item.populate():
File “/usr/share/qgis/python/plugins/db_manager/db_model.py”, line 182, in populate
if not connection.connect():
File “/usr/share/qgis/python/plugins/db_manager/db_plugins/spatialite/plugin.py”, line 78, in connect
return self.connectToUri(uri)
File “/usr/share/qgis/python/plugins/db_manager/db_plugins/plugin.py”, line 142, in connectToUri
self.db = self.databasesFactory(self, uri)
File “/usr/share/qgis/python/plugins/db_manager/db_plugins/spatialite/plugin.py”, line 64, in databasesFactory
return SLDatabase(connection, uri)
File “/usr/share/qgis/python/plugins/db_manager/db_plugins/spatialite/plugin.py”, line 107, in init
Database.init(self, connection, uri)
File “/usr/share/qgis/python/plugins/db_manager/db_plugins/plugin.py”, line 267, in init
self.connector = self.connectorsFactory(uri)
File “/usr/share/qgis/python/plugins/db_manager/db_plugins/spatialite/plugin.py”, line 110, in connectorsFactory
return SpatiaLiteDBConnector(uri)
File “/usr/share/qgis/python/plugins/db_manager/db_plugins/spatialite/connector.py”, line 51, in init
self.connection = spatialite_connect(self._connectionInfo())
File “/usr/share/qgis/python/qgis/utils.py”, line 684, in spatialite_connect
raise RuntimeError(“Cannot find any suitable spatialite module”)
RuntimeError: Cannot find any suitable spatialite module

Can anyone help me sort this out.
BR, Eduardo

2

Hi
Is libspatialite7 installed?

3

Hi
yes libspatialite7 is installed
BR

4

Forgot to mention I’m running kde

5

For the record, I am running Tumbleweed and QGIS 3.18.2-Zürich and can start tge DB Manager without problems, but I have no databases configured.

I see more information is available on https://github.com/qgis/QGIS/issues/42925 and there the comment is “this seems really a local issue… not a QGIS problem.”

I found the source file that is emitting this error, and based on that you see it is searching for:

libs = 
# SpatiaLite >= 4.2 and Sqlite >= 3.7.17, should work on all platforms
("mod_spatialite", "sqlite3_modspatialite_init"),
# SpatiaLite >= 4.2 and Sqlite < 3.7.17 (Travis)
("mod_spatialite.so", "sqlite3_modspatialite_init"),
# SpatiaLite < 4.2 (linux)
("libspatialite.so", "sqlite3_extension_init")
]

Using "sudo zypper se “sudo zypper se spatialite” I see I have libspatialite7 installed but there is also libspatialite (without the 7).

Do you also have libspatialite7 installed? If not, please install it an retry,
If you have it installed, you can try to install also libspatialite to see if that makes a difference

Can you also check the output of following command

> find /usr/share/qgis/python/ -name '*spatialite*' 
/usr/share/qgis/python/plugins/db_manager/db_plugins/spatialite
6

Hi
here is the output of the command

sudo zypper se spatialite
Cargando datos del repositorio...
Leyendo los paquetes instalados...

S  | Name                         | Summary                                                                  | Type
---+------------------------------+--------------------------------------------------------------------------+------------
   | libspatialite                | Spatial SQLite                                                           | paquete src
   | libspatialite-debugsource    | Debug sources for package libspatialite                                  | paquete
   | libspatialite-devel          | Development files for libspatialite                                      | paquete
i+ | libspatialite7               | Spatial SQLite                                                           | paquete
   | libspatialite7-debuginfo     | Debug information for package libspatialite7                             | paquete
   | spatialite-tools             | A collection of Command Line Interface (CLI) tools supporting SpatiaLite | paquete src
   | spatialite-tools             | A collection of Command Line Interface (CLI) tools supporting SpatiaLite | paquete
   | spatialite-tools-debuginfo   | Debug information for package spatialite-tools                           | paquete
   | spatialite-tools-debugsource | Debug sources for package spatialite-tools                               | paquete

I have libspatialite7 installed but not libspatialite.
If I try to install it via yast online it doesn’t seem to be available, it shows only as source packet.

The output of the other command you suggest is

find /usr/share/qgis/python/ -name '*spatialite*'
/usr/share/qgis/python/plugins/db_manager/db_plugins/spatialite

BR, Eduardo

7

I have found where to install spatialite (without 7) from

https://software.opensuse.org/download/package?package=libspatialite&project=openSUSE%3ALeap%3A15.2

according to that instruction I should execute

zypper addrepo https://download.opensuse.org/repositories/openSUSE:Leap:15.2/standard/openSUSE:Leap:15.2.repo
zypper refresh
zypper install libspatialite

but that repo doesn’t work

sudo zypper addrepo https://download.opensuse.org/repositories/openSUSE:Leap:15.2/standard/openSUSE:Leap:15.2.repo
No se encuentra el archivo /repositories/openSUSE:Leap:15.2/standard/openSUSE:Leap:15.2.repo en el medio https://download.opensuse.org/
¿Cancelar, reintentar o ignorar? [a/r/i/...? mostrar todas las opciones] (a): a

BR, Eduardo

8

Okay, you have the same package installed as me running on Tumbleweed.

I played a bit around.

With the error mentioning spatialite I found the main Browser menu also has an entry SpatiaLite so I did give that a try and created a test table:
https://paste.opensuse.org/images/53317518.png

That was all fine.
Then I opened up the “DB Manager” and tried to open under “SpatailLite” my newly created test.sqlite and that is triggering the error:

https://susepaste.org/images/69390995.png

The stack trace is the same as in the the first post.

I had a better look at the code, found https://www.sqlite.org/loadext.html and it looks to me it is some sqlite functionality and I think I can reproduce this from the command line using:

> sqlite3
SQLite version 3.35.5 2021-04-19 18:32:05 
Enter ".help" for usage hints. 
Connected to a **transient in-memory database**. 
[FONT=monospace]sqlite> select load_extension("libspatialite.so", "sqlite3_extension_init");
Error: libspatialite.so.so: cannot open shared object file: No such file or directory
sqlite> select load_extension("mod_spatialite.so", "sqlite3_modspatialite_init");               
Error: mod_spatialite.so.so: cannot open shared object file: No such file or directory
sqlite> select load_extension("mod_spatialite", "sqlite3_modspatialite_init"); 
Error: mod_spatialite.so: cannot open shared object file: No such file or directory
[/FONT][FONT=monospace]sqlite> .quit
[/FONT]

I see I have both shared objects:

> find /usr -name 'libspatialite*'
/usr/lib64/libspatialite.so.7
/usr/lib64/libspatialite.so.7.1.0
/usr/lib64/qgis/libspatialiteprovider.so
/usr/share/licenses/libspatialite7
/usr/share/doc/packages/libspatialite7
> find /usr -name 'mod_spatialite*'
/usr/lib64/mod_spatialite.so.7.1.0
/usr/lib64/mod_spatialite.so.7

Reading https://www.sqlite.org/loadext.html and found out you can run also “select load_extension” without the second “entry point” and I tried that but same error, so the problem is that sqlite3 can not find these shared objects.

> cat /etc/ld.so.conf 
/usr/local/lib64 
/usr/local/lib 
include /etc/ld.so.conf.d/*.conf 
# /lib64, /lib, /usr/lib64 and /usr/lib gets added 
# automatically by ldconfig after parsing this file. 
# So, they do not need to be listed.

My libspatialite.so.7 and my mod_spatialite.so.7 are in /usr/lib64/ so that looks good.
Using strace (a lot of debug output so the interpretation is fuzzy logic) it looks to me sqlite3 is looking for the module name without the .7 at the end

openat(AT_FDCWD, "/usr/lib64/x86_64/mod_spatialite", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
openat(AT_FDCWD, "/usr/lib64/mod_spatialite", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
openat(AT_FDCWD, "/lib64/mod_spatialite.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
openat(AT_FDCWD, "/usr/lib64/mod_spatialite.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

So that points back again on the availablity of the libspatialite package.

9

Okay, not sure if the problem is that the libspatialite is not available (also tried on Tumbleweed, “No provider of ‘libspatialite’ found.”)

On https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html I read:

Thus, /usr/lib/libreadline.so.3 is a fully-qualified soname, which ldconfig would set to be a symbolic link to some realname like /usr/lib/libreadline.so.3.0. There should also be a linker name, /usr/lib/libreadline.so which could be a symbolic link referring to /usr/lib/libreadline.so.3.

So is the problem that a /usr/lib64/mod_spatialite.so symbolic link to /usr/lib64/mod_spatialite.so.7 is missing?
I know the install process should do that somehow but I also know how to make symbolic links so:

> sudo ln -s /usr/lib64/mod_spatialite.so.7 /usr/lib64/mod_spatialite.so 
> sqlite3 
SQLite version 3.35.5 2021-04-19 18:32:05 
Enter ".help" for usage hints. 
Connected to a **transient in-memory database**. 
Use ".open FILENAME" to reopen on a persistent database. 
sqlite> select load_extension("mod_spatialite", "sqlite3_modspatialite_init");  
sqlite>

No error anymore so that is a work-around.

I still think it would be good to fix the root cause. It looks to me that some install script does not set up this symbolic link. That needs more work and some guidance would be helpful.

10

Hi Marel

Creating the symbolic link as you suggested did the trick.
Now the Data Base Administration window seems to be as it should.
I hope I can now complete the GIS course.

I guess it is an installation error as you mention.

thanks ever so much for your asistance
BR, Eduardo

pd: I’m not very familiar with the forum, should I mark the issue as solved and closed?

11

I updated the issue on github with your findings and they closed it
BR

12

Yes, this is no QGIS issue but a Opensuse packaging problem.

On the problem, I see the module is provided for me (running on Thumbleweed) by

> rpm -qif /usr/lib64/mod_spatialite.so.7    
Name        : libspatialite7 
Version     : 4.3.0a 
Release     : 15.41 
Architecture: x86_64 
Install Date: Sun Apr 25 15:39:20 2021 
Group       : System/Libraries 
Size        : 12571136 
License     : MPL-1.1 
Signature   : DSA/SHA1, Thu Apr 22 08:45:52 2021, Key ID 01db7302943d8bb8 
Source RPM  : libspatialite-4.3.0a-15.41.src.rpm 
Build Date  : Thu Apr 22 08:43:46 2021 
Build Host  : goat03 
Vendor      : obs://build.opensuse.org/science
URL         : http://www.gaia-gis.it/spatialite/ 
Summary     : Spatial SQLite 
Description : 
The SpatiaLite extension enables SQLite to support spatial data too [aka 
GEOMETRY], in a way conformant to OpenGis specifications. 
Distribution: science / openSUSE_Tumbleweed

That is remarkable, it is from obs://build.opensuse.org/science, I would have expected from Application:Geo
And yes, there are two packages:

  1. http://download.opensuse.org/repositories/science/openSUSE_Tumbleweed/x86_64/libspatialite7-4.3.0a-15.41.x86_64.rpm
  2. http://download.opensuse.org/repositories/Application:/Geo/openSUSE_Tumbleweed/x86_64/libspatialite7-4.3.0a-14.34.x86_64.rpm

The one from Science is newer, so is that the reason zypper did choice that?

Next question, what is in the .rpm?

> rpm -ql http://download.opensuse.org/repositories/science/openSUSE_Tumbleweed/x86_64/libspatialite7-4.3.0a-15.41.x86_64.rpm
/usr/lib64/libspatialite.so.7
/usr/lib64/libspatialite.so.7.1.0
/usr/lib64/mod_spatialite.so.7
/usr/lib64/mod_spatialite.so.7.1.0
/usr/share/doc/packages/libspatialite7
/usr/share/doc/packages/libspatialite7/README
/usr/share/doc/packages/libspatialite7/README.coverage
/usr/share/licenses/libspatialite7
/usr/share/licenses/libspatialite7/COPYING
> rpm -qp --scripts http://download.opensuse.org/repositories/science/openSUSE_Tumbleweed/x86_64/libspatialite7-4.3.0a-15.41.x86_64.rpm
postinstall program: /sbin/ldconfig
postuninstall program: /sbin/ldconfig

The output is the same for the Application:Geo version.

So what is ldconfig doing?

> sudo /sbin/ldconfig -v | grep libspatialite
        libspatialite.so.7 -> libspatialite.so.7.1.0

Still not clear to me who is responsible for creating the libspatialite.so → libspatialite.so.7 symlink…

13

More things not clear, where is libspatialite7 coming from?

On the official SpatiaLite page I see “current version is 5.0.1 (released on 2021-02-07)” and searching on the Internet lispatialite**7 **seems to be an Opensuse thing.

Also remarkable is that there are 4 libspatialite packages:

  1. libspatialite-debugsource-4.3.0a-15.41.x86_64.rpm
  2. libspatialite-devel-4.3.0a-15.41.x86_64.rpm
  3. libspatialite7-4.3.0a-15.41.x86_64.rpm
  4. libspatialite7-debuginfo-4.3.0a-15.41.x86_64.rpm

And I can only find the Science libspatialite package on build.opensuse.org not libspatialite7
Found that there is in the libspatialite.spec file:

%define sover   7
%define libname %{name}%{sover}
Name:           libspatialite
Version:        4.3.0a

I guess solving the issue is a matter of removing the first two lines but is that a good idea? :\

NB: The Application:Geo package has exactly the same issue.

14

Hi
No, that is the shared library version…
Best idea is a bug report… openSUSE:Submitting bug reports - openSUSE

15

Bug submitted: https://bugzilla.opensuse.org/show_bug.cgi?id=1185415

Yes, 7 is the shared library version but I see quite some packages that does not define it and it is unclear to me why libspatialite would need it.

16

Hi
Because it’s a shared library packaging policy if not there will fail… openSUSE:Shared library packaging policy - openSUSE Wiki