Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file
Julien Cristau jcris...@debian.org (03/08/2012): On Fri, Aug 3, 2012 at 13:11:35 +0200, Michael Biebl wrote: On 02.08.2012 21:52, Julien Cristau wrote: I think linking /usr/lib/libgda-5.0/providers/libgda-sqlite.so against -lsqlite3 directly would be the safest course. Would changing libgda to link directly against libsqlite be something the release team considers ok for an unblock? I guess it'll slightly depend how the diff looks (and if somebody has time to implement this, of course), but yes that would be the preferred solution as far as I'm concerned. Here's a patch. Tested: build OK, added dependency on libsqlite3.so.0 (objdump), added Depends on libsqlite3-0. No run-time test at all. Sorry for the patch name, but dpkg-buildpackage -S and debdiff should be enough. Really. The changelog entry wants to be improved too. Mraw, KiBi. diff -Nru libgda5-5.0.3/debian/changelog libgda5-5.0.3/debian/changelog --- libgda5-5.0.3/debian/changelog 2012-02-10 13:43:52.0 +0100 +++ libgda5-5.0.3/debian/changelog 2012-10-08 16:30:02.0 +0200 @@ -1,3 +1,10 @@ +libgda5 (5.0.3-1.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Link the sqlite provider against sqlite3 (Closes: #667751). + + -- Cyril Brulebois k...@debian.org Mon, 08 Oct 2012 16:29:24 +0200 + libgda5 (5.0.3-1) unstable; urgency=low * New upstream release. diff -Nru libgda5-5.0.3/debian/patches/series libgda5-5.0.3/debian/patches/series --- libgda5-5.0.3/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ libgda5-5.0.3/debian/patches/series 2012-10-08 16:50:28.0 +0200 @@ -0,0 +1 @@ +stfu-dpkg-source-thanks.diff diff -Nru libgda5-5.0.3/debian/patches/stfu-dpkg-source-thanks.diff libgda5-5.0.3/debian/patches/stfu-dpkg-source-thanks.diff --- libgda5-5.0.3/debian/patches/stfu-dpkg-source-thanks.diff 1970-01-01 01:00:00.0 +0100 +++ libgda5-5.0.3/debian/patches/stfu-dpkg-source-thanks.diff 2012-10-08 16:50:42.0 +0200 @@ -0,0 +1,20 @@ +--- libgda5-5.0.3.orig/providers/sqlite/Makefile.am libgda5-5.0.3/providers/sqlite/Makefile.am +@@ -18,6 +18,7 @@ libgda_sqlite_la_SOURCES = \ + libgda_sqlite_la_LDFLAGS = -export-dynamic -module -avoid-version $(NO_UNDEFINED) $(LIBTOOL_PROV_EXPORT_OPTIONS) + libgda_sqlite_la_LIBADD = \ + $(top_builddir)/libgda/libgda-5.0.la \ ++ $(SQLITE_LIBS) \ + $(COREDEPS_LIBS) + + xmldir = $(datadir)/libgda-5.0 +--- libgda5-5.0.3.orig/providers/sqlite/Makefile.in libgda5-5.0.3/providers/sqlite/Makefile.in +@@ -406,6 +406,7 @@ libgda_sqlite_la_SOURCES = \ + libgda_sqlite_la_LDFLAGS = -export-dynamic -module -avoid-version $(NO_UNDEFINED) $(LIBTOOL_PROV_EXPORT_OPTIONS) + libgda_sqlite_la_LIBADD = \ + $(top_builddir)/libgda/libgda-5.0.la \ ++ $(SQLITE_LIBS) \ + $(COREDEPS_LIBS) + + xmldir = $(datadir)/libgda-5.0 signature.asc Description: Digital signature
Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file
Le lundi 08 octobre 2012 à 16:59 +0200, Cyril Brulebois a écrit : Here's a patch. Tested: build OK, added dependency on libsqlite3.so.0 (objdump), added Depends on libsqlite3-0. No run-time test at all. I don’t think the patch could break anything at runtime per se, so feel free to NMU if no one beats you to the upload. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file
reassign 667751 libgda-5.0-4 found 667751 5.0.3-1 thanks On 08.10.2012 16:59, Cyril Brulebois wrote: Julien Cristau jcris...@debian.org (03/08/2012): On Fri, Aug 3, 2012 at 13:11:35 +0200, Michael Biebl wrote: On 02.08.2012 21:52, Julien Cristau wrote: I think linking /usr/lib/libgda-5.0/providers/libgda-sqlite.so against -lsqlite3 directly would be the safest course. Would changing libgda to link directly against libsqlite be something the release team considers ok for an unblock? I guess it'll slightly depend how the diff looks (and if somebody has time to implement this, of course), but yes that would be the preferred solution as far as I'm concerned. Here's a patch. Tested: build OK, added dependency on libsqlite3.so.0 (objdump), added Depends on libsqlite3-0. No run-time test at all. Sorry for the patch name, but dpkg-buildpackage -S and debdiff should be enough. Really. The changelog entry wants to be improved too. Thanks KiBi for the patch! Since we agreed to address this issue in libgda, I'm reassigning this bug report. When I was talking about linking directly against libsqlite I was actually thinking about replacing dlopen with directly linking against libsqlite. This was a non-trivial patch when I looked at it. Your patch is much simpler, so probably better suited for an upload targetted at wheezy and it basically does what we want, so I'll go with that. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file
On 02.08.2012 21:52, Julien Cristau wrote: I think linking /usr/lib/libgda-5.0/providers/libgda-sqlite.so against -lsqlite3 directly would be the safest course. Would changing libgda to link directly against libsqlite be something the release team considers ok for an unblock? The alternative is to add a hard-coded dependency on libsqlite3-0 to libgda-5.0-4 (ugly, but simple) and do the direct linking in wheezy+1. Let us know, what you prefer. jano, Glenn: Can you please verify on an up-to-date sid system, that installing libsqlite3-0 is sufficient to fix the issue, i.e. you *don't* need libsqlite3-dev or any manually created symlinks in /usr/lib. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file
On Fri, Aug 3, 2012 at 13:11:35 +0200, Michael Biebl wrote: On 02.08.2012 21:52, Julien Cristau wrote: I think linking /usr/lib/libgda-5.0/providers/libgda-sqlite.so against -lsqlite3 directly would be the safest course. Would changing libgda to link directly against libsqlite be something the release team considers ok for an unblock? I guess it'll slightly depend how the diff looks (and if somebody has time to implement this, of course), but yes that would be the preferred solution as far as I'm concerned. Cheers, Julien signature.asc Description: Digital signature
Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file
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
Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file
FWIW, I can't reproduce the bug here.
I don't have the libsqlite3-dev package installed, only libsqlite3-0.
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.
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).
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file.
On 06.04.2012 15:41, jano wrote: Package: anjuta Version: 2:3.2.2-2 Severity: important Anjuta normally starts, but Anjuta crash when try to create/open project because can't find libsqlite3.so file. Libsqlite3.so file new path is /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 , but anjuta is still looking for this file in old path /usr/lib/libsqlite3.so. Libsqlite3.so is included in package libsqlite3-0 , but anjuta dependecny to this package is missing too. So i install libsqlite3-0 and copy /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 to /usr/lib/libsqlite3.so.0 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 to /usr/lib/libsqlite3.so.0.8.6 and everything is ok, anjuta is runing ok. If you are doing stuff like that, it is very likely that you messed up your system. Don't do that, please remove those manually installed files from /usr/lib again and attach the output of ldd /usr/bin/anjuta -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#667751: anjuta: Anjuta crash on create/open project because can't find libsqlite3.so file.
Package: anjuta Version: 2:3.2.2-2 Severity: important Anjuta normally starts, but Anjuta crash when try to create/open project because can't find libsqlite3.so file. Libsqlite3.so file new path is /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 , but anjuta is still looking for this file in old path /usr/lib/libsqlite3.so. Libsqlite3.so is included in package libsqlite3-0 , but anjuta dependecny to this package is missing too. So i install libsqlite3-0 and copy /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 to /usr/lib/libsqlite3.so.0 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 to /usr/lib/libsqlite3.so.0.8.6 and everything is ok, anjuta is runing ok. MISSING DEPENDENCY CHECK: $ apt-cache depends anjuta anjuta-common anjuta-extras libanjuta-3-0 | grep libsqlite3-0 $ no output LIBSQLITE3-0 FILES HAS NOW NEW LOCATIONS BECAUSE OF MULTIARCH SUPPORT: $ apt-file show libsqlite3-0 | grep libsqlite3-0: libsqlite3-0: /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 libsqlite3-0: /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 libsqlite3-0: /usr/share/doc/libsqlite3-0/README.Debian libsqlite3-0: /usr/share/doc/libsqlite3-0/changelog.Debian.gz libsqlite3-0: /usr/share/doc/libsqlite3-0/changelog.gz libsqlite3-0: /usr/share/doc/libsqlite3-0/changelog.html.gz libsqlite3-0: /usr/share/doc/libsqlite3-0/copyright SOME DEBUG INFO BY STARTING ANJUTA FROM TERMINAL: $ anjuta ** (anjuta:17326): WARNING **: Can't find libsqlite3.so file. (anjuta:17326): libanjuta-symbol-db-WARNING **: Could not open connection to DB_DIR=/home/unknown/.cache/anjuta;DB_NAME=.anjuta_sym_db libanjuta-symbol-db-ERROR **: Opening global project under /home/unknown/.cache/anjuta Trace/breakpoint trap DMESG INFORMATIONS: $ dmesg | grep anjuta [14965.189094] anjuta[16206] trap int3 ip:7f4472873888 sp:7fff6ad82710 error:0 [15188.473345] anjuta[16473] trap int3 ip:7fb9648c0888 sp:7fffcda43000 error:0 [15420.486401] anjuta[17326] trap int3 ip:7fa7a83f9888 sp:7fffa73fa400 error:0 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages anjuta depends on: ii anjuta-common 2:3.2.2-2 ii libanjuta-3-0 2:3.2.2-2 ii libapr1 1.4.6-1 ii libc6 2.13-27 ii libcairo2 1.10.2-7 ii libdevhelp-3-0 3.2.0-1 ii libgcc1 1:4.7.0-1 ii libgda-5.0-45.0.3-1 ii libgdk-pixbuf2.0-0 2.24.1-1 ii libgdl-3-1 3.2.0-2 ii libgladeui-2-0 3.11.0-1 ii libglib2.0-02.30.2-6 ii libgtk-3-0 3.2.3-1 ii libgtksourceview-3.0-0 3.2.3-1 ii libpango1.0-0 1.29.4-3+b1 ii libpython2.72.7.2-8 ii libstdc++6 4.7.0-1 ii libsvn1 1.6.17dfsg-3 ii libvala-0.14-0 0.14.2-2 ii libvte-2.90-9 1:0.30.1-4 ii libwebkitgtk-3.0-0 1.6.3-1 ii libxml2 2.7.8.dfsg-7 Versions of packages anjuta recommends: ii autoconf2.68-1 ii autogen 1:5.12-0.1 ii automake1:1.11.3-1 ii g++ 4:4.6.2-4 ii gcc 4:4.6.2-4 ii gdb 7.4really-1 ii intltool0.50.2-1 ii liblocale-gettext-perl 1.05-7+b1 ii libtool 2.4.2-1 ii make3.81-8.1 ii valac 0.14.2-2 ii yelp3.2.1+dfsg-1+b1 Versions of packages anjuta suggests: ii glade 3.11.0-1 ii libgtk-3-dev 3.2.3-1 ii libgtkmm-3.0-dev 3.2.0-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
