Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file

[Julien Cristau]

Hi Michael,

On Sun, Jul 29, 2012 at 13:14:14 +0200, Michael Biebl wrote:

> FWIW, I can't reproduce the bug here.
> I don't have the libsqlite3-dev package installed, only libsqlite3-0.
> 
Same here, libsqlite3.so.0 gets loaded properly AFAICT.

> plugins/symbol-db/symbol-db-engine-core.c
> does have
> 
> > /* establish a connection. If the sqlite file does not exist it will 
> >  * be created 
> >  */
> > priv->db_connection = gda_connection_open_from_string ("SQLite", cnc_string, NULL, 
> > 									   GDA_CONNECTION_OPTIONS_THREAD_SAFE, NULL);	
> > 
> > if (!GDA_IS_CONNECTION (priv->db_connection))
> > {
> > 	g_warning ("Could not open connection to %s\n", cnc_string);
> > 	return FALSE;		
> > }
> 
> 
> libgda loads sqlite via dlopen that's why the anjuta package doesn't
> have a direct dependency on libsqlite3-0.
> 
This stuff looks crazy to me.  It's going to break the day there's a
libsqlite3 SONAME bump (see below).

> There are two issues which we need to consider
> 1/ Either we make sure libsqlite3-0 is installed by adding a depends on
> it or we handle a missing libsqlite3-0 more gracefully and do not
> segfault if missing. Maybe we should do both.
> 
> Thinking more about this, this is probably a bug in libgda-5.0-4. The
> libgda-5.0-4 package ships
> /usr/lib/libgda-5.0/providers/libgda-sqlite.so but does not have
> dependency on libsqlite3-0 while it probably should, even though it
> *only* loads that lib via dlopen.
> 
> We can argue that applications using gda_connection_open_from_string
> ("SQLite",...) need to depend on libsqlite3-0 themselves or we add that
> dependency to libgda-5.0-4 so applications linking against libgda don't
> need to take care of that.
> 
> I'd like to have more opinions from other (GNOME) maintainers about this
> which approach we should take.
> 
> 2/ Verify that libgda correctly loads libsqlite from multiarch paths. As
> said, this seems to work fine for me so I guess we need to find out why
> gda_connection_open_from_string ("SQLite",...) fails for other users. In
> libgda/sqlite/gda-symbols-util.c:find_sqlite_library is responsible to
> load the libsqlite3 library, which uses a builtin search path first and
> then falls back to g_module_open which TTBOMK is aware of multiarch
> paths (I'm pretty sure it is).
> 
From what I can tell (from a strace) it does readdir() on
/usr/lib/x86_64-linux-gnu, looking for something called libsqlite3.so.*
I guess, and then loads that.  Ick.

I think linking /usr/lib/libgda-5.0/providers/libgda-sqlite.so against
-lsqlite3 directly would be the safest course.

Cheers,
Julien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20120802/a4adfdf2/attachment.pgp>