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
signature.asc
Description: Digital signature
